Rule 5-2-6 and dynamicaly loading (.dll / .so)

Moderators: david ward, misra cpp

udi
Posts: 8
Joined: Wed May 11, 2016 8:24 am
Company: Elbit

Rule 5-2-6 and dynamicaly loading (.dll / .so)

Postby udi » Tue Dec 18, 2018 8:42 am

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.

dg1980
Posts: 108
Joined: Wed Apr 27, 2016 2:33 pm
Company: Elektrobit Automotive GmbH

Re: Rule 5-2-6 and dynamicaly loading (.dll / .so)

Postby dg1980 » Tue Dec 18, 2018 12:07 pm

I think the behavior of explicit dynamic linking with dlopen/dlsym is undefined if the function signature does not match:

Code: Select all

int (*ptr)(void) = static_cast<int (*)(void)>(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. -llibrary) because of the type checking involved.

udi
Posts: 8
Joined: Wed May 11, 2016 8:24 am
Company: Elbit

Re: Rule 5-2-6 and dynamicaly loading (.dll / .so)

Postby udi » Tue Dec 18, 2018 12:30 pm

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.

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.

misra cpp
Posts: 145
Joined: Mon Jun 02, 2008 1:55 pm
Company: MISRA

Re: Rule 5-2-6 and dynamicaly loading (.dll / .so)

Postby misra cpp » Wed Jan 30, 2019 10:22 am

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.
Posted by and on behalf of
the MISRA C++ Working Group


Return to “6.5 Expressions (C++)”

Who is online

Users browsing this forum: No registered users and 0 guests