From: Craig Howland <howland@LGSInnovations.com>
To: "newlib@sourceware.org" <newlib@sourceware.org>
Subject: Re: Use of initialized variable in strtod.c
Date: Wed, 15 Mar 2017 18:56:00 -0000 [thread overview]
Message-ID: <2264cd14-0e03-2aad-f95e-562394435c0b@LGSInnovations.com> (raw)
In-Reply-To: <47ea65c0-130a-e138-3c7c-0c1a636d87fd@oarcorp.com>
On 03/15/2017 02:38 PM, Joel Sherrill wrote:
>
>
> On 3/15/2017 1:34 PM, Craig Howland wrote:
>> On 03/15/2017 02:16 PM, Joel Sherrill wrote:
>>> ...
>>>
>>> Basically if (bb) is false, then bits is not set
>>> and it is used as input to ULtod.
>>>
>>> 334 if (bb) {
>>> 335 copybits(bits, fpi.nbits, bb);
>>> 336 Bfree(ptr,bb);
>>> 337 }
>>>
>>> CID 175379 (#1 of 1): Uninitialized scalar variable (UNINIT)
>>> 10. uninit_use_in_call: Using uninitialized element of array bits when calling
>>> ULtod. [show details]
>>> 338 ULtod(rv.i, bits, exp, i);
>>>
>> I took a quick look, and I think (it's been ages since I had to do some editing
>> in strtod.c) it is OK. Specifically, it does appear that bb is only ever
>> returned as 0 in a case when ULtod does not need the value of bits. So while
>> Coverity it right that it could be a problem, it is not really.
>
> Would it be better to initialize bb to 0? Or assign it on
> the else to "if (bb)". If that's correct, it would make
> the intent clearer and eliminate the use of an uninitialized
> variable.
>
> FWIW I am a firm believer in not marking issues as false
> positive. In this case, there really is a use of an
> uninitialized variable. So we might as well address that.
>
I disagree that there really is use of an uninitialized variable. There is not.
It just appears to the tool that there is. (This is a tough case, so it's not a
surprise that it misses it and gives a false indictment.)
Does Coverity have a way in which in the code it can be marked as OK? (I'd
expect some '#pragma CoverityIgnore(bits)' or the like ought to be available.)
I agree with trying to get rid of the message, but it is worth bloat to do it?
(It will add instructions to either initialize bits to 0 or add the else.) I
would rather mark something in the code as a false positive than add code
because the tool is not smart enough to know--so we might differ in philosophy
there. I do agree that using out-of-band notes to say to ignore a message would
be undesirable--but still an interesting question against unnecessarily
increasing code size. Adding a Coverity pragma would be best, as then the tool
would automatically get the report right. (If I added initialization every time
GCC complained, I'd get noticeably bigger. Perhaps Coverity does a much better
job and much less would need to be added to appease it, but I have no experience
with it to know.) Perhaps Corinna or Jeff can weigh in to set a policy.
Craig
next prev parent reply other threads:[~2017-03-15 18:56 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-15 18:16 Joel Sherrill
2017-03-15 18:34 ` Craig Howland
2017-03-15 18:38 ` Joel Sherrill
2017-03-15 18:56 ` Craig Howland [this message]
2017-03-15 19:31 ` Jeffrey Walton
2017-03-15 19:54 ` Joel Sherrill
2017-03-15 20:03 ` Joel Sherrill
2017-03-15 22:37 ` Joel Sherrill
2017-03-15 22:47 ` Craig Howland
2017-03-16 8:32 ` Corinna Vinschen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2264cd14-0e03-2aad-f95e-562394435c0b@LGSInnovations.com \
--to=howland@lgsinnovations.com \
--cc=newlib@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).