--device parameter on the command line not recognized

[avtechscientific]

--device parameter on the command line not recognized

[cyclaero]

I changed line 1128 of cl.hpp to:

        param->assign(value.begin(), (value.back() != '\0') ? value.end() : value.end()-1);

This takes care of a trailing nuls in case any buggy OpenCL driver insists on delivering it. Doesn't look too clumsy, does it?

The alternative is not to advertise the macOS as a working platform anymore, because without taking care of the nuls in the one or the other form, ASL would be useless on the Mac.

[AvtechScientific]

Those trailing '\0' chars are delivered by buggy OpenCL drivers. The problem is that a bad driver produces them and a good driver doesn't - with the same hardware and on the same OS. So you have to check whether they exist and if yes - strip them. We are not sure, however, that we should correct issues caused by bad drivers by making our code more clumsy.

[cyclaero]

Those trailing '\0' chars are delivered by buggy OpenCL drivers.

It is quite hard for me to understand how this could happen, since any OpenCL driver is supposed to return a C string, i.e. a C array of chars terminated by a nul char, isn´t it?

Do OpenCL drivers on Linux really provide non-terminated arrays of chars? Isn´t it rather the C++ side which gives rise for a lot of confusion about subtle differences between character arrays and strings. My impression comes from searching Google about "C++ string trailing nul". Seems that the confusion started with the switch from C++11 to C++14. On macOS 10.12.6 the code is compiled with the latest clang++ (which is C++11) are you working with a C++14-compiler?

[AvtechScientific]

Hi @cyclaero,

an elegant solution, indeed. And most importantly - cl.hpp is not actually ASL, but rather an C++wrapper to OpenCL - so it is the right place to take care of the issue. Do you want to make a Pull Request with this fix (and maybe your first solved issue as well)? We'll need to test them on a non Mac platform though...

Thank you!

[cyclaero]

I had a closer look on the upstream C++-API headers on https://github.com/KhronosGroup/OpenCL-CLHPP. And it turned out, that the issue has been resolved in cl2.hpp on exactly the same place which I already suggested, however with a less C'ish and more C++'ish solution. So, I decided to go for back porting the upstream cl2 fix.

I cloned your repository to my GitHub account, I updated cl.hpp to the upstream version 1.2.9 and then back ported 2 fixes from cl2.hpp to the present cl.hpp for the specialized GetInfoHelper for string params, namely fix the trailing '\0' issue and the empty string result issue. Chances are that this would simply work on the vast majority of platforms since these fixes contain only code snippets which came from the Khronos Group.

see: cyclaero@a38f1d4

If this approach is OK for you, then I would submit a pull request, if not, then please inform.