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

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...]

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.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: free() and implicit conversion to a function pointer

[L A Walsh]

Going by subj and talk below, this is a bit confusing...

But it looks like you are testing 'free' for a value?

Isn't standard 'free' declared to take 1 arg and
return void?

If you aren't talking standard 'free()', then
nevermind...


Hans-Bernhard Bröker wrote:
> [Sorry, forgot to reply-all...]
>
> 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.
---
Free autodecays to a function pointer?
In what language?

It's not a C-function nor a C function pointer.



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: free() and implicit conversion to a function pointer

[Hans-Bernhard Bröker]

Am 16.03.2017 um 22:46 schrieb L A Walsh:
> Going by subj and talk below, this is a bit confusing...
>
> But it looks like you are testing 'free' for a value?

Not really.  The idea is to test free for _exixtence_.  Which only makes 
sense in case of weak symbol support getting involved.  In other 
situations, there could not possibly be a need for a run-time if() test, 
because surely the code could know at build time whether free() exists 
or not.

> Isn't standard 'free' declared to take 1 arg and
> return void?

Yes.  But since the code in question doesn't actually _call_ free, 
that's both irrelevant.

> If you aren't talking standard 'free()', then
> nevermind...

We are talking standard free.  More to the point, we're discussing 
newlib, the package that actually implements free() for cygwin.

>> 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.
> ---
> Free autodecays to a function pointer?

In the use case at hand: yes, it does.

> In what language?

Standard C.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: free() and implicit conversion to a function pointer

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1714 bytes --]

On Mar 17 00:49, Hans-Bernhard Bröker wrote:
> Am 16.03.2017 um 22:46 schrieb L A Walsh:
> > Going by subj and talk below, this is a bit confusing...
> > 
> > But it looks like you are testing 'free' for a value?
> 
> Not really.  The idea is to test free for _exixtence_.  Which only makes
> sense in case of weak symbol support getting involved.  In other situations,
> there could not possibly be a need for a run-time if() test, because surely
> the code could know at build time whether free() exists or not.
> 
> > Isn't standard 'free' declared to take 1 arg and
> > return void?
> 
> Yes.  But since the code in question doesn't actually _call_ free, that's
> both irrelevant.
> 
> > If you aren't talking standard 'free()', then
> > nevermind...
> 
> We are talking standard free.  More to the point, we're discussing newlib,
> the package that actually implements free() for cygwin.
> 
> > > 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.
> > ---
> > Free autodecays to a function pointer?
> 
> In the use case at hand: yes, it does.
> 
> > In what language?
> 
> Standard C.

Wasn't that supposed to go to the newlib list where this has been
discussed originally?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: free() and implicit conversion to a function pointer

[Hans-Bernhard Bröker]

Am 17.03.2017 um 09:30 schrieb Corinna Vinschen:
> On Mar 17 00:49, Hans-Bernhard Bröker wrote:
[...]

> Wasn't that supposed to go to the newlib list where this has been
> discussed originally?

Ah, of course it was.  That explains the confusion, too.  Sorry for that.

I'll repost there.

HBB


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: free() and implicit conversion to a function pointer

[Eric Blake]

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

On 03/16/2017 02:24 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).

-- 
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 --]