From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 36446 invoked by alias); 15 Mar 2017 18:56:16 -0000 Mailing-List: contact newlib-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: newlib-owner@sourceware.org Received: (qmail 35462 invoked by uid 89); 15 Mar 2017 18:56:16 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=cid, Howland, howland, H*f:sk:f573307 X-HELO: mail01.lgsinnovations.com Received: from mail01.lgsinnovations.com (HELO mail01.lgsinnovations.com) (184.75.234.233) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 15 Mar 2017 18:56:14 +0000 Subject: Re: Use of initialized variable in strtod.c To: "newlib@sourceware.org" References: <788987e9-9b0d-4bfd-b40a-38c219bd8a17@oarcorp.com> <47ea65c0-130a-e138-3c7c-0c1a636d87fd@oarcorp.com> From: Craig Howland Message-ID: <2264cd14-0e03-2aad-f95e-562394435c0b@LGSInnovations.com> Date: Wed, 15 Mar 2017 18:56:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <47ea65c0-130a-e138-3c7c-0c1a636d87fd@oarcorp.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LGS-EX05.lgsdirect.com (135.22.48.227) To LGS-EX01.lgsdirect.com (135.22.77.164) X-IsSubscribed: yes X-SW-Source: 2017/txt/msg00178.txt.bz2 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