public inbox for newlib@sourceware.org
 help / color / mirror / Atom feed
* free() and implicit conversion to a function pointer (was: Use of initialized variable in strtod.c)
@ 2017-03-15 22:48 Jeffrey Walton
  2017-03-16  8:40 ` Corinna Vinschen
  0 siblings, 1 reply; 4+ messages in thread
From: Jeffrey Walton @ 2017-03-15 22:48 UTC (permalink / raw)
  To: Joel Sherrill; +Cc: newlib

> But this in __call_atexit.c is definitely correct. It is
> treating free() as a weak symbol and the only way to
> silence Coverity is to add an annotation.
>
> 136      /* Don't dynamically free the atexit array if free is not
> 137         available.  */
>
> CID 175323 (#1 of 1): Function address comparison (BAD_COMPARE)
> func_conv: This implicit conversion to a function pointer is suspicious:
> free.
>         Did you intend to call free?
> 138      if (!free)
> 139        break;

Well, I have not encountered that one (yet). 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;

If that works to clear the finding, then it is one of those items I
write-off as "working and playing well with the tools".

Jeff

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: free() and implicit conversion to a function pointer (was: Use of initialized variable in strtod.c)
  2017-03-15 22:48 free() and implicit conversion to a function pointer (was: Use of initialized variable in strtod.c) Jeffrey Walton
@ 2017-03-16  8:40 ` Corinna Vinschen
  2017-03-16 15:04   ` Joel Sherrill
  0 siblings, 1 reply; 4+ messages in thread
From: Corinna Vinschen @ 2017-03-16  8:40 UTC (permalink / raw)
  To: newlib

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

On Mar 15 18:48, Jeffrey Walton wrote:
> > But this in __call_atexit.c is definitely correct. It is
> > treating free() as a weak symbol and the only way to
> > silence Coverity is to add an annotation.
> >
> > 136      /* Don't dynamically free the atexit array if free is not
> > 137         available.  */
> >
> > CID 175323 (#1 of 1): Function address comparison (BAD_COMPARE)
> > func_conv: This implicit conversion to a function pointer is suspicious:
> > free.
> >         Did you intend to call free?
> > 138      if (!free)
> > 139        break;
> 
> Well, I have not encountered that one (yet). 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;
> 
> If that works to clear the finding, then it is one of those items I
> write-off as "working and playing well with the tools".

Unfortunately you have to tell covreity that "free" is a var, not a function,
but since that's not generally true... marking as false positive.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: free() and implicit conversion to a function pointer (was: Use of initialized variable in strtod.c)
  2017-03-16  8:40 ` Corinna Vinschen
@ 2017-03-16 15:04   ` Joel Sherrill
  2017-03-16 16:23     ` Bob Dunlop
  0 siblings, 1 reply; 4+ messages in thread
From: Joel Sherrill @ 2017-03-16 15:04 UTC (permalink / raw)
  To: newlib



On 3/16/2017 3:39 AM, Corinna Vinschen wrote:
> On Mar 15 18:48, Jeffrey Walton wrote:
>>> But this in __call_atexit.c is definitely correct. It is
>>> treating free() as a weak symbol and the only way to
>>> silence Coverity is to add an annotation.
>>>
>>> 136      /* Don't dynamically free the atexit array if free is not
>>> 137         available.  */
>>>
>>> CID 175323 (#1 of 1): Function address comparison (BAD_COMPARE)
>>> func_conv: This implicit conversion to a function pointer is suspicious:
>>> free.
>>>         Did you intend to call free?
>>> 138      if (!free)
>>> 139        break;
>>
>> Well, I have not encountered that one (yet). 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;
>>
>> If that works to clear the finding, then it is one of those items I
>> write-off as "working and playing well with the tools".
>
> Unfortunately you have to tell covreity that "free" is a var, not a function,
> but since that's not generally true... marking as false positive.
>

Looks like the second option resolves the issue. No Coverity specific
markup at all. It seems better to be explicit since comparing a function
name to NULL directly is rather unusual.

--joel

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: free() and implicit conversion to a function pointer (was: Use of initialized variable in strtod.c)
  2017-03-16 15:04   ` Joel Sherrill
@ 2017-03-16 16:23     ` Bob Dunlop
  0 siblings, 0 replies; 4+ messages in thread
From: Bob Dunlop @ 2017-03-16 16:23 UTC (permalink / raw)
  To: Joel Sherrill; +Cc: newlib

On Thu, Mar 16 at 10:04, Joel Sherrill wrote:
> 
> On 3/16/2017 3:39 AM, Corinna Vinschen wrote:
> > On Mar 15 18:48, Jeffrey Walton wrote:
> >>> But this in __call_atexit.c is definitely correct. It is
> >>> treating free() as a weak symbol and the only way to
> >>> silence Coverity is to add an annotation.
> >>>
> >>> 136      /* Don't dynamically free the atexit array if free is not
> >>> 137         available.  */
> >>>
> >>> CID 175323 (#1 of 1): Function address comparison (BAD_COMPARE)
> >>> func_conv: This implicit conversion to a function pointer is suspicious:
> >>> free.
> >>>         Did you intend to call free?
> >>> 138      if (!free)
> >>> 139        break;
> >>
> >> Well, I have not encountered that one (yet). 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;
> >>
> >> If that works to clear the finding, then it is one of those items I
> >> write-off as "working and playing well with the tools".
> >
> > Unfortunately you have to tell covreity that "free" is a var, not a function,
> > but since that's not generally true... marking as false positive.
> >
> 
> Looks like the second option resolves the issue. No Coverity specific
> markup at all. It seems better to be explicit since comparing a function
> name to NULL directly is rather unusual.
> 
> --joel


Have you not just inverted the sense of the test as well.
Shouldn't it be:

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

-- 
        Bob Dunlop

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2017-03-16 16:23 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-03-15 22:48 free() and implicit conversion to a function pointer (was: Use of initialized variable in strtod.c) Jeffrey Walton
2017-03-16  8:40 ` Corinna Vinschen
2017-03-16 15:04   ` Joel Sherrill
2017-03-16 16:23     ` Bob Dunlop

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