From: Jeff Garzik <jeff@garzik.org>
To: Daniel Walker <dwalker@mvista.com>
Cc: Andrew Morton <akpm@osdl.org>,
Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: Announce: gcc bogus warning repository
Date: Sun, 01 Oct 2006 14:45:28 -0400 [thread overview]
Message-ID: <45200CC8.2030404@garzik.org> (raw)
In-Reply-To: <1159727188.24767.9.camel@c-67-180-230-165.hsd1.ca.comcast.net>
Daniel Walker wrote:
> On Sun, 2006-10-01 at 14:16 -0400, Jeff Garzik wrote:
>> Andrew Morton wrote:
>>> The downsides are that it muckies up the source a little and introduces a
>>> very small risk that real use-uninitialised bugs will be hidden. But I
>>> believe the benefit outweighs those disadvantages.
>> How about just marking the ones I've already done in #gccbug?
>>
>> If I'm taking the time to audit the code, and separate out bogosities
>> from real bugs, it would be nice not to see that effort wasted.
>
> There was a long thread on this, it's not about anyone not reviewing the
> code properly when the warning is first silenced. It's that future
> changes might create new problems that are also silenced. I don't think
> it's a huge concern, especially since there's was a config option to
> turn the warning backs on.
That doesn't address my question at all.
If there is no difference between real non-init bugs and bogus warnings,
then a config option doesn't make any difference at all, does it? Real
bugs are still hidden either way: if the warnings are turned on, the
bugs are lost in the noise. if the warnings are turned off, the bugs
are completely hidden.
Jeff
next prev parent reply other threads:[~2006-10-01 18:45 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-01 13:44 Announce: gcc bogus warning repository Jeff Garzik
2006-10-01 13:56 ` Al Viro
2006-10-01 15:40 ` Daniel Walker
2006-10-01 18:12 ` Andrew Morton
2006-10-01 18:16 ` Jeff Garzik
2006-10-01 18:26 ` Daniel Walker
2006-10-01 18:45 ` Jeff Garzik [this message]
2006-10-01 18:58 ` Daniel Walker
2006-10-01 19:00 ` Al Viro
2006-10-01 19:03 ` Daniel Walker
2006-10-01 19:07 ` Al Viro
2006-10-01 19:13 ` Daniel Walker
2006-10-01 19:20 ` Al Viro
2006-10-01 19:25 ` Daniel Walker
2006-10-01 19:33 ` Al Viro
2006-10-01 21:45 ` Andrew Morton
2006-10-01 20:24 ` Roland Dreier
2006-10-02 11:39 ` linux-os (Dick Johnson)
2006-10-01 17:07 ` Randy Dunlap
2006-10-01 17:20 ` Jeff Garzik
2006-10-01 17:27 ` Alistair John Strachan
2006-10-01 17:45 ` Adrian Bunk
2006-10-01 18:16 ` Randy Dunlap
2006-10-04 16:19 ` Jörn Engel
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=45200CC8.2030404@garzik.org \
--to=jeff@garzik.org \
--cc=akpm@osdl.org \
--cc=dwalker@mvista.com \
--cc=linux-kernel@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.