Re: Use of initialized variable in strtod.c

[Corinna Vinschen <vinschen@redhat.com>]

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

On Mar 15 14:56, Craig Howland wrote:
> 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?

Just mark it as false positive in coverity.  We should not change the
code in this area too much.  It's basically David M. Gay's gdtoa code
and we should keep it in a shape easier comparable with upstream.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

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