This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Use of initialized variable in strtod.c


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]