implicit casts in API headers must be replaced for C++ support

[pabigot]

Various headers take advantage of the fact that C allows implicit casts of void* to other pointer types, e.g.:

..., void* ptr, ....
struct mine *p = ptr;

However this code is erroneous in C++, causing build errors when these headers are included.

Since Zephyr does support C++ in application code, implicit casts should be replaced by explicit casts in any header that provides API to applications.

[aescolar]

@pabigot Something like this does indeed make sense to fix. But note that C++ support is quite experimental. So classifying it as a bug, is maybe a bit borderline. So I will set it to low.
(note that we cannot be in a situation where somebody adds some experimental support for a new feature, and we end up blocking all progress anywhere else until that feature is mature enough).

Also note that bug reports like this one are problematic, as it is quite unbound, it does not point to anything in particular, and sets the burden of proof of the bug having been fixed in whoever is fixing it.

[stephanosio]

For future reference on the implicit void pointer type conversion error in the C++ compilers:

GCC

• -fpermissive option can be used to downgrade such errors to warnings.
• There is no option to disable such warnings.

Clang

• There is no option to allow an implicit void pointer type conversion.
• Such a behaviour will always be treated as an error.

[pabigot]

@aescolar The documentation says nothing about C++ support being "quite experimental" and there are a lot of long-standing bugs related to it, one of which is medium priority, for which we've only just found a viable solution.

I agree the problem is unbound, but I don't see how to focus it. Since we don't have anything that checks conformance on PR submission (not even for things uncrustify can identify) problems will continue to be introduced. Which is why I plan to address this using Coccinelle.

[aescolar]

Sidetracking

The documentation says nothing about C++ support being "quite experimental"

@pabigot that is probably what we should be fixing first.