Fwd: Re: free() and implicit conversion to a function pointer (was: Use of initialized variable in strtod.c)

Fwd: Re: free() and implicit conversion to a function pointer (was: Use of initialized variable in strtod.c)

[Hans-Bernhard Bröker]

[Sorry, forgot to reply-all, then reply-all-ed to the wrong list...]

Am 15.03.2017 um 23:48 schrieb Jeffrey Walton:

> Since Coverity is
> complaining about an implicit conversion, maybe the following will
> help to avoid the implicit part (and sidestep the finding):
>
>     if (free != NULL)
>         break;
>
> Or perhaps:
>
>     if ((void*)free != NULL)
>         break;

Even setting aside that the latter should of course have been

      if ((void*)free == NULL)
          break;

those are both worse than the original code.  (void *) is _not_ suitable 
for use with function pointers.  Neither is NULL in the general case, 
because it may very well be ((void *)0).

The reason this is wrong is that C by design treats data and functions 
as living in separate realms, i.e. its virtual machine has a Harvard 
architecture.  One of the consequences of this is that pointers to 
functions and pointers to data are incommensurable, i.e. any and all 
conversions or comparisons across this divide are wrong.  (void *) are 
compatible to all data pointers, but not to function pointers.

The only code that might actually be a slight bit better than the given

	if (! free)

would be

	if (0 != free)

The function designator `free' auto-decays into a function pointer, 
which is compared to a null pointer constant: 0.  The ! operator does 
that same thing implicitly, but is fully equivalent to it.

In other words: that message from Coverity is just _wrong_, so it 
_should_ be disabled.

Re: Fwd: Re: free() and implicit conversion to a function pointer (was: Use of initialized variable in strtod.c)

[Eric Blake]

[-- Attachment #1.1: Type: text/plain, Size: 1093 bytes --]

On 03/17/2017 04:04 PM, Hans-Bernhard Bröker wrote:

> The reason this is wrong is that C by design treats data and functions
> as living in separate realms, i.e. its virtual machine has a Harvard
> architecture.  One of the consequences of this is that pointers to
> functions and pointers to data are incommensurable, i.e. any and all
> conversions or comparisons across this divide are wrong.  (void *) are
> compatible to all data pointers, but not to function pointers.

That's true of strict C99, but not true of POSIX (which adds the
additional requirements above-and-beyond C99 that NULL be equivalent to
((void*)0) and that any function pointer can be converted to void* and
back without loss of information, in part because of dlsym() and friends).

Then again, not all newlib targets aim for POSIX compliance, and it is
entirely feasible that someone is trying to use newlib to achieve C99
compliance without caring about additional POSIX requirements.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

Re: Fwd: Re: free() and implicit conversion to a function pointer (was: Use of initialized variable in strtod.c)

[Jeffrey Walton]

>> The reason this is wrong is that C by design treats data and functions
>> as living in separate realms, i.e. its virtual machine has a Harvard
>> architecture.  One of the consequences of this is that pointers to
>> functions and pointers to data are incommensurable, i.e. any and all
>> conversions or comparisons across this divide are wrong.  (void *) are
>> compatible to all data pointers, but not to function pointers.
>
> That's true of strict C99, but not true of POSIX (which adds the
> additional requirements above-and-beyond C99 that NULL be equivalent to
> ((void*)0) and that any function pointer can be converted to void* and
> back without loss of information, in part because of dlsym() and friends).
>
> Then again, not all newlib targets aim for POSIX compliance, and it is
> entirely feasible that someone is trying to use newlib to achieve C99
> compliance without caring about additional POSIX requirements.

+1. When I test for compatibility or ST&E, then I will test some
stated features even if I don't use them. -std=c99, -ansi and
_XOPEN_SOURCE are usually easy enough to test.

(Newlib confounds me at the moment, though. I have not figured out an
easy way to test it).

Jeff