[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0702131513050.3604@woody.linux-foundation.org>
Date: Tue, 13 Feb 2007 15:21:04 -0800 (PST)
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Sergei Organov <osv@...ad.com>
cc: Pekka Enberg <penberg@...helsinki.fi>,
J.A. MagallÃÃón
<jamagallon@....com>, Jan Engelhardt <jengelh@...ux01.gwdg.de>,
Jeff Garzik <jeff@...zik.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: somebody dropped a (warning) bomb
On Tue, 13 Feb 2007, Sergei Organov wrote:
>
> Sorry, what do you do with "variable 'xxx' might be used uninitialized"
> warning when it's false? Turn it off? Annotate the source? Assign fake
> initialization value? Change the compiler so that it does "the effort"
> for you? Never encountered false positive from this warning?
The thing is, that warning is at least easy to shut up.
You just add a fake initialization. There isn't any real downside.
In contrast, to shut up the idiotic pointer-sign warning, you have to add
a cast.
Now, some people seem to think that adding casts is a way of life, and
think that C programs always have a lot of casts. That's NOT TRUE. It's
actually possible to avoid casts, and good C practice will do that to
quite a high degree, because casts in C are *dangerous*.
A language that doesn't allow arbitrary type-casting is a horrible
language (because it doesn't allow you to "get out" of the language type
system), and typecasts in C are really important. But they are an
important feature that should be used with caution, and as little as
possible, because they (by design, of course) break the type rules.
Now, since the _only_ reason for the -Wpointer-sign warning in the first
place is to warn about breaking type rules, if the way to shut it up is to
break them EVEN MORE, then the warnign is obviously totally broken. IT
CAUSES PEOPLE TO WRITE WORSE CODE! Which was against the whole point of
having the warning in the first place.
This is why certain warnings are fine. For example, the warning about
if (a=b)
..
is obviously warning about totally valid C code, but it's _still_ a fine
warning, because it's actually very easy to make that warning go away AND
IMPROVE THE CODE at the same time. Even if you actually meant to write the
assignment, you can write it as
if ((a = b) != 0)
..
or
a = b;
if (a)
..
both of which are actually more readable.
But if you have
unsigned char *mystring;
len = strlen(mystring);
then please tell me how to fix that warning without making the code
*worse* from a type-safety standpoint? You CANNOT. You'd have to cast it
explicitly (or assing it through a "void *" variable), both of which
actually MAKE THE TYPE-CHECKING PROBLEM WORSE!
See? The warning made no sense to begin with, and it warns about something
where the alternatives are worse than what it warned about.
Ergo. It's a crap warning.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists