From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 73517 invoked by alias); 16 Mar 2017 08:32:01 -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 72132 invoked by uid 89); 16 Mar 2017 08:32:00 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=H*MI:sk:2264cd1, cid, H*i:sk:2264cd1, firm X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 16 Mar 2017 08:31:58 +0000 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2D3F261988 for ; Thu, 16 Mar 2017 08:31:59 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 2D3F261988 Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=vinschen@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 2D3F261988 Received: from calimero.vinschen.de (ovpn-117-18.ams2.redhat.com [10.36.117.18]) by smtp.corp.redhat.com (Postfix) with ESMTP id C48FC6031D for ; Thu, 16 Mar 2017 08:31:58 +0000 (UTC) Received: by calimero.vinschen.de (Postfix, from userid 500) id ACB26A805A1; Thu, 16 Mar 2017 09:31:56 +0100 (CET) Date: Thu, 16 Mar 2017 08:32:00 -0000 From: Corinna Vinschen To: newlib@sourceware.org Subject: Re: Use of initialized variable in strtod.c Message-ID: <20170316083156.GB16777@calimero.vinschen.de> Reply-To: newlib@sourceware.org Mail-Followup-To: newlib@sourceware.org References: <788987e9-9b0d-4bfd-b40a-38c219bd8a17@oarcorp.com> <47ea65c0-130a-e138-3c7c-0c1a636d87fd@oarcorp.com> <2264cd14-0e03-2aad-f95e-562394435c0b@LGSInnovations.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="xXmbgvnjoT4axfJE" Content-Disposition: inline In-Reply-To: <2264cd14-0e03-2aad-f95e-562394435c0b@LGSInnovations.com> User-Agent: Mutt/1.8.0 (2017-02-23) X-SW-Source: 2017/txt/msg00186.txt.bz2 --xXmbgvnjoT4axfJE Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 2340 On Mar 15 14:56, Craig Howland wrote: > On 03/15/2017 02:38 PM, Joel Sherrill wrote: > >=20 > >=20 > > On 3/15/2017 1:34 PM, Craig Howland wrote: > > > On 03/15/2017 02:16 PM, Joel Sherrill wrote: > > > > ... > > > >=20 > > > > Basically if (bb) is false, then bits is not set > > > > and it is used as input to ULtod. > > > >=20 > > > > 334 if (bb) { > > > > 335 copybits(bits, fpi.nbits= , bb); > > > > 336 Bfree(ptr,bb); > > > > 337 } > > > >=20 > > > > CID 175379 (#1 of 1): Uninitialized scalar variable (UNINIT) > > > > 10. uninit_use_in_call: Using uninitialized element of array bits w= hen calling > > > > ULtod. [show details] > > > > 338 ULtod(rv.i, bits, exp, i); > > > >=20 > > > I took a quick look, and I think (it's been ages since I had to do so= me 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. > >=20 > > 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. > >=20 > > 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. > >=20 > 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.) >=20 > 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 wor= th > 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 --=20 Corinna Vinschen Cygwin Maintainer Red Hat --xXmbgvnjoT4axfJE Content-Type: application/pgp-signature; name="signature.asc" Content-length: 819 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJYyk18AAoJEPU2Bp2uRE+gSUMP/jSZyWwztMT1V/AzDCvM51P5 OAAkIsdHA6+Rd9ctp3wEt1L7cjOLSnfihnT/3/lQ+ydLWWprDXkaLYH8CoCOzVVH 75gExPIftMRnVsYifpFld4CdMvrhM4W7ltt6p5lWH4V8V4kDDNH+oI7Ex8wRfXYk kRJby/gg5uGKBYD2FmxE8gFInBG9uz5FsQwDxmPVw5K5DNcqqdkHPIU1JAGPhRy4 dkmI1rCdN/Xz0Xa4/kpdkbswMwdrYC06oQJNB5ZMFLUv/ARj+PAXBJ6zZ5WUi6R/ DUW+PZdHUCJVE9cvGTgCSb779R/nPdbvP/Ww1yPWqKtO6AMftSB1TUbu4ChyGoun +eJsfv6j2DdRItn2oaXRfraDmxUtHftyU0tHXT/BlLONzzbEjGdYRx/FkSju7/nd 8WJ4mm0PF+nC4uy98iX/LZHChxa2zcdmKDkvT+8RxjoOdgvgwo5aVAH2Qp6JqcBT 1XKWNwimNfnKHsXRK6cQylRo/GDW06r+UUms/ThTICRN8rUHpk6ieRnBy/NS3nwy UFDLz77t/dEtSCciQCImPGug/izyJAnYYiZ+SswMz2uyvh6U/UIFwmMRZXoJxuet XnexoSPz/YCtYdz343Zwt0DLviQ+ne5Y2hUjZEOWzCle9ddk9S8MudKr8ytNc6kY SPdWtzNLVb30jRXUkj/s =86MF -----END PGP SIGNATURE----- --xXmbgvnjoT4axfJE--