From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 61624 invoked by alias); 15 Mar 2017 19:31:25 -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 61614 invoked by uid 89); 15 Mar 2017 19:31:24 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=UD:scan.coverity.com, Newlib, sk:scanco, sk:scan.co X-HELO: mail-ot0-f171.google.com Received: from mail-ot0-f171.google.com (HELO mail-ot0-f171.google.com) (74.125.82.171) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 15 Mar 2017 19:31:22 +0000 Received: by mail-ot0-f171.google.com with SMTP id x37so30908367ota.2 for ; Wed, 15 Mar 2017 12:31:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to; bh=iCdVo9NZnadsyUtokcrlJsw0O9/Scfp7l+bWQAA1GaA=; b=Ejw1yQB+JPwEYpuERA08aI+kphBcgUr9T3qk/TVdbw8oXjiX9x8ZJ5lZgCGki8FM2E NylEVDlUYs9X8Du2RAHKOvW6ydnFuXbZUzorscGS/bb7I8W0vkCUSgOn/qD/WKS5Aw9W t0ZZJvhTgxtHjU2dk99iguMzGEGWNIcXwfwCRsGKBLYDPbAe7UamGougqWrWTH49DCYm EgRXTv4VZ9sL1HT3F1vE+vYDlxJt2X8P82W3KuqJIv4q2c4Nz6NKGR9KYpd8asg/YR6o gdO9rklPggCZxS5WEI3Kh/C9QLFcDK+/jpW8P1tHAGaE+qCuxWe9Itmb6pYIHk2YzkNA F8Aw== X-Gm-Message-State: AFeK/H39FcV3EDIhUMADZRm5JgoxKkQ2CveVHRCtDal5ln0WMP+6yl2+mw3feGNuFYVDkZD+2p6jHFAKTuBwUg== X-Received: by 10.202.198.67 with SMTP id w64mr396279oif.158.1489606281908; Wed, 15 Mar 2017 12:31:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.31.131 with HTTP; Wed, 15 Mar 2017 12:31:21 -0700 (PDT) Reply-To: noloader@gmail.com In-Reply-To: <2264cd14-0e03-2aad-f95e-562394435c0b@LGSInnovations.com> References: <788987e9-9b0d-4bfd-b40a-38c219bd8a17@oarcorp.com> <47ea65c0-130a-e138-3c7c-0c1a636d87fd@oarcorp.com> <2264cd14-0e03-2aad-f95e-562394435c0b@LGSInnovations.com> From: Jeffrey Walton Date: Wed, 15 Mar 2017 19:31:00 -0000 Message-ID: Subject: Re: Use of initialized variable in strtod.c To: newlib@sourceware.org Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2017/txt/msg00179.txt.bz2 > 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.) Yes. You have to provide a modeling file. Also see the Coverity Scan FAQ entry "what is a model" at https://scan.coverity.com/faq. Other projects use them, like Python. See, for example, https://docs.python.org/devguide/coverity.html. > 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.) If I am parsing things correctly, it seems like the bloat is going the other way: if the code is not needed, then remove it. It will avoid findings like these, and speed up the compile. > 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. Perhaps a better strategy would be to initialize all variables, and then allow the optimizer to remove the unneeded writes. It will ensure a program is in a good state, and avoid findings like these. Another strategy is to do nothing. In this case, the same findings will waste multiple developer's time, and generate additional mailing list messages. I like dark and silent cockpits, so I don't want tools generating findings, and I don't want mailing list messages. I would squash it once and for all and avoid all future problems. But that's just me, and I understand the Newlib project may have a different outlook on things. Jeff