All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.