Use of initialized variable in strtod.c

[Craig Howland]

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