From: dewar@gnat.com
To: carlo@alinoe.com, dalej@apple.com
Cc: amylaar@redhat.com, gcc@gcc.gnu.org, jbuck@synopsys.COM,
kevina@users.sourceforge.net
Subject: Re: Uninitialized warnings
Date: Tue, 17 Jul 2001 20:03:00 -0000 [thread overview]
Message-ID: <20010718030314.57E06F2B45@nile.gnat.com> (raw)
<<Believe it or not, I agree with you, but I'm definitely in a small
minority (1?) around here. Is there a consensus on how the
uninitialized-variable check should behave?
>>
A bug that is found by examining a warning at compile time represents a huge
cost savings over having to find this same bug during unit testing, system
integration testing, or worse, not finding it at all and having it cause
damage after deployment.
That means to me that one is willing to tolerate quite a few false positives
to find one real bug at compile time.
I do agree that you need a way to selectively turn off warnings so that
sources can be kept clean.
A specific case in point is that when we first ran the GNAT sources through
GCC 3.x, we got about 60 warnings about possibly uninitialized variables.
Six of these were definite bugs, and one of them was a potentially serious
bug. Going through those 60 warnings to find that potentially serious bug
*before* it caused someone trouble was *well* worth the effort.
next reply other threads:[~2001-07-17 20:03 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-07-17 20:03 dewar [this message]
-- strict thread matches above, loose matches on Subject: below --
2001-07-18 9:55 dewar
2001-07-18 17:11 ` Richard Henderson
2001-07-17 19:55 dewar
2001-07-16 20:20 Compile Time Memory Leak Analyses Kevin Atkinson
2001-07-17 9:51 ` Uninitialized warnings Dale Johannesen
2001-07-17 15:33 ` Carlo Wood
2001-07-17 16:02 ` Dale Johannesen
2001-07-18 6:24 ` Stan Shebs
2001-07-18 6:40 ` Diego Novillo
1998-02-17 14:10 uninitialized warnings Jeffrey A Law
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20010718030314.57E06F2B45@nile.gnat.com \
--to=dewar@gnat.com \
--cc=amylaar@redhat.com \
--cc=carlo@alinoe.com \
--cc=dalej@apple.com \
--cc=gcc@gcc.gnu.org \
--cc=jbuck@synopsys.COM \
--cc=kevina@users.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).