* Re: free() and implicit conversion to a function pointer (was: Use of initialized variable in strtod.c)
[not found] <c5af0608-17c4-2270-dbba-c3b704c9226e@t-online.de>
@ 2017-03-16 19:25 ` Hans-Bernhard Bröker
2017-03-16 21:46 ` free() and implicit conversion to a function pointer L A Walsh
2017-03-20 18:43 ` Eric Blake
0 siblings, 2 replies; 6+ messages in thread
From: Hans-Bernhard Bröker @ 2017-03-16 19:25 UTC (permalink / raw)
To: cygwin
[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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: free() and implicit conversion to a function pointer
2017-03-16 19:25 ` free() and implicit conversion to a function pointer (was: Use of initialized variable in strtod.c) Hans-Bernhard Bröker
@ 2017-03-16 21:46 ` L A Walsh
2017-03-16 23:49 ` Hans-Bernhard Bröker
2017-03-20 18:43 ` Eric Blake
1 sibling, 1 reply; 6+ messages in thread
From: L A Walsh @ 2017-03-16 21:46 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: free() and implicit conversion to a function pointer
2017-03-16 21:46 ` free() and implicit conversion to a function pointer L A Walsh
@ 2017-03-16 23:49 ` Hans-Bernhard Bröker
2017-03-17 8:30 ` Corinna Vinschen
0 siblings, 1 reply; 6+ messages in thread
From: Hans-Bernhard Bröker @ 2017-03-16 23:49 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: free() and implicit conversion to a function pointer
2017-03-16 23:49 ` Hans-Bernhard Bröker
@ 2017-03-17 8:30 ` Corinna Vinschen
2017-03-17 21:01 ` Hans-Bernhard Bröker
0 siblings, 1 reply; 6+ messages in thread
From: Corinna Vinschen @ 2017-03-17 8:30 UTC (permalink / raw)
To: cygwin
[-- 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 --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: free() and implicit conversion to a function pointer
2017-03-17 8:30 ` Corinna Vinschen
@ 2017-03-17 21:01 ` Hans-Bernhard Bröker
0 siblings, 0 replies; 6+ messages in thread
From: Hans-Bernhard Bröker @ 2017-03-17 21:01 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: free() and implicit conversion to a function pointer
2017-03-16 19:25 ` free() and implicit conversion to a function pointer (was: Use of initialized variable in strtod.c) Hans-Bernhard Bröker
2017-03-16 21:46 ` free() and implicit conversion to a function pointer L A Walsh
@ 2017-03-20 18:43 ` Eric Blake
1 sibling, 0 replies; 6+ messages in thread
From: Eric Blake @ 2017-03-20 18:43 UTC (permalink / raw)
To: cygwin
[-- 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 --]
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-03-20 18:43 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <c5af0608-17c4-2270-dbba-c3b704c9226e@t-online.de>
2017-03-16 19:25 ` free() and implicit conversion to a function pointer (was: Use of initialized variable in strtod.c) Hans-Bernhard Bröker
2017-03-16 21:46 ` free() and implicit conversion to a function pointer L A Walsh
2017-03-16 23:49 ` Hans-Bernhard Bröker
2017-03-17 8:30 ` Corinna Vinschen
2017-03-17 21:01 ` Hans-Bernhard Bröker
2017-03-20 18:43 ` Eric Blake
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).