* Fwd: Re: free() and implicit conversion to a function pointer (was: Use of initialized variable in strtod.c) [not found] <f76885f4-f99f-dc50-2a19-cb892a62db7e@t-online.de> @ 2017-03-17 21:04 ` Hans-Bernhard Bröker 2017-03-20 18:45 ` Eric Blake 0 siblings, 1 reply; 3+ messages in thread From: Hans-Bernhard Bröker @ 2017-03-17 21:04 UTC (permalink / raw) To: newlib [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. ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Fwd: Re: free() and implicit conversion to a function pointer (was: Use of initialized variable in strtod.c) 2017-03-17 21:04 ` Fwd: Re: free() and implicit conversion to a function pointer (was: Use of initialized variable in strtod.c) Hans-Bernhard Bröker @ 2017-03-20 18:45 ` Eric Blake 2017-03-20 18:57 ` Jeffrey Walton 0 siblings, 1 reply; 3+ messages in thread From: Eric Blake @ 2017-03-20 18:45 UTC (permalink / raw) To: Hans-Bernhard Bröker, newlib [-- 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 --] ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Fwd: Re: free() and implicit conversion to a function pointer (was: Use of initialized variable in strtod.c) 2017-03-20 18:45 ` Eric Blake @ 2017-03-20 18:57 ` Jeffrey Walton 0 siblings, 0 replies; 3+ messages in thread From: Jeffrey Walton @ 2017-03-20 18:57 UTC (permalink / raw) To: Eric Blake; +Cc: newlib >> 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2017-03-20 18:57 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <f76885f4-f99f-dc50-2a19-cb892a62db7e@t-online.de> 2017-03-17 21:04 ` Fwd: Re: free() and implicit conversion to a function pointer (was: Use of initialized variable in strtod.c) Hans-Bernhard Bröker 2017-03-20 18:45 ` Eric Blake 2017-03-20 18:57 ` Jeffrey Walton
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).