From: Ingo Molnar <mingo@elte.hu>
To: Jean Delvare <khali@linux-fr.org>
Cc: Takashi Iwai <tiwai@suse.de>,
Rufus & Azrael <rufus-azrael@numericable.fr>,
Linux-kernel Mailing List <linux-kernel@vger.kernel.org>,
Jaswinder Singh Rajput <jaswinderlinux@gmail.com>
Subject: Re: [2.6.29-rc2-git2] compilation warnings
Date: Tue, 27 Jan 2009 14:06:08 +0100 [thread overview]
Message-ID: <20090127130608.GD23121@elte.hu> (raw)
In-Reply-To: <20090127134854.1a9992fd@hyperion.delvare>
* Jean Delvare <khali@linux-fr.org> wrote:
> Hi Takashi,
>
> On Tue, 27 Jan 2009 10:34:20 +0100, Takashi Iwai wrote:
> > At Tue, 27 Jan 2009 09:46:28 +0100,
> > > On Tue, 27 Jan 2009 08:32:17 +0100, Takashi Iwai wrote:
> > > > A bogus warning. Ignore this.
> > >
> > > No matter how bogus it is, it should be fixed. Otherwise this is
> > > wasting the time of users and developers over and over again.
> >
> > Well, it's a bug of gcc appearing only in a certain version, so most
> > people won't see it.
> >
> > Of course, we can put uninitialized_var(). But, I don't basically
> > like adding it unconditionally...
>
> I didn't know about uninitialized_var(), thanks for the hint.
>
> My experience with these warnings is that, in many cases, it is possible
> to write the code differently so that it is clear to the compiler that
> the variable is never used uninitialized. In some cases, doing so also
> makes the code easier to read for humans and less likely to break in the
> future.
>
> Of course, in some cases the problem is simply that the compiler is too
> stupid to understand even simple things, but in other cases these
> warnings might be a good opportunity to rewrite the code in a way that
> is easier to understand.
And even in the cases where the compiler is stupid, leaving a warning
around:
1) Does not get compiler bugs fixed any faster [only true competition
between compilers gets compiler bugs fixed any faster]
2) Has ongoing and irreversible maintenance costs for _all of us in the
kernel_
3) for every bogus compiler warning there's a dozen warnings where the
compiler told us that _we_ were doing something stupid. All things
considered the false positive ratio is still a fair deal.
So leaving them around is a bit like making a political point by burning
yourself in front of the cameras - leaves the political opponent largely
unimpressed and unscathed while being self-destructive in 99% of the
cases.
gcc_is_utterly_stupid(var) type of annotations (that initialize to zero
instead of the current 'turn off the warning' dangerous construct) would
be far better. Albeit even that would in all likelyhood be a rather
pointless (but admittedly satisfying) gesture.
Ingo
next prev parent reply other threads:[~2009-01-27 13:06 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-27 7:15 [2.6.29-rc2-git2] compilation warnings Rufus & Azrael
2009-01-27 7:32 ` Takashi Iwai
2009-01-27 8:46 ` Jean Delvare
2009-01-27 9:34 ` Takashi Iwai
2009-01-27 11:16 ` Ingo Molnar
2009-01-27 11:49 ` Takashi Iwai
2009-01-27 12:48 ` Jean Delvare
2009-01-27 13:06 ` Ingo Molnar [this message]
2009-01-27 8:44 ` Jaswinder Singh Rajput
2009-01-27 8:44 ` Jean Delvare
2009-01-27 11:18 ` Ingo Molnar
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=20090127130608.GD23121@elte.hu \
--to=mingo@elte.hu \
--cc=jaswinderlinux@gmail.com \
--cc=khali@linux-fr.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rufus-azrael@numericable.fr \
--cc=tiwai@suse.de \
/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.