The rule forbids conversion between function pointer types.
I believe that this rule should exempt a function retrieved with GetProcAddress / dlsym, as I believe this is not an undefined / unspecified behavior (or is it?).
It might make sense to add a requirement to review and document these cases.
I think the behavior of explicit dynamic linking with dlopen/dlsym is undefined if the function signature does not match:
Code:
int (*ptr)(void) = static_cast(dlsym(handle, "func"));// no way to check the return value e.g. the signature of func
if (ptr != nullptr)
ptr();// undefined behavior if func is not defined as int func(void) inside the shared object
I would always prefer implicit dynamic linking (e.g. -l
library) because of the type checking involved.
Quote:I think the behavior of explicit dynamic linking with dlopen/dlsym is undefined if the function signature does not match:
You might be right about this, but the way this rule is written, it prevents the use of this functionality
even if the signatures match.
Quote:I would always prefer implicit dynamic linking (e.g. -llibrary) because of the type checking involved
I would also prefer this, but this prevents me from supllying an SDK, for which a project can write its own plugins.
Same problem arises if I am using a 3rd party SDK.
You are correct, 5-2-6 bans all casts to/from function pointer types.
MISRA C++ only considers the language as defined by the C++ standard. GetProcAddress and dlsym are from operating system specific libraries (Windows and Linux), so any special treatment of them is outside the scope of this document.
However, their use can be addressed by raising a deviation. For further guidance, see the MISRA Compliance document – in effect the review and document solution you propose.