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

Moderators: david ward, misra cpp

udi
Posts: 7
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: 102
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: 7
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.


Return to “6.5 Expressions (C++)”

Who is online

Users browsing this forum: No registered users and 0 guests