"sparse" warnings..

[linas at austin.ibm.com]

On Mon, May 03, 2004 at 11:04:35AM -0700, Linus Torvalds wrote:
>
> > About a year ago, we fixed some real-live bugs due to comparisons to
> > "-1" done on unsigned quantities.
>
> in fact gcc will warn about this in at least some
> incarnations ("comparison can never be true due to limited type" or

Indeed, the current gcc's do catch this; too bad that wasn't the case
a year ago ...

> similar). So while I might add that warning to sparse, I don't have any
> huge incentives simply because it already exists as a "regular C"
> warning.

Hmm, well, then, ideally, then, it would be best if gcc could find all
of the 'regular' C (and cpp) syntax confusions on its own;  while
something like 'sparse' concentrated on kernel-only issues (whatever
those may be?)


> One thing I've been considering adding is a "no-implicit-cast" attribute,
> which would make it a warning if such a type is ever implicitly cast to
> another type. That _would_ warn about things like the above, ie it would
> have warned about "thingy()" being implicitly promoted to an "int" for the
> comparison.
>
> But I'm not sure how useful such an attribute would be.

The only thing I can think of that's even vaguely like this is taking
a bitflag, say a short, having one of the bit-fields map to the
sign-bit, and then accidentally (implicitly) sign-extending it and
getting unexpected results.  e.g.

#define  ENABLE_X   1<<15

short   mybits = 0;

mybits |= ENABLE_X;

long device_word;

device_word = 0x300000 | mybits;

You can call this 'bad programming style', but the none-the-less, the
result is surprising, because the error doesn't occur if ENABLE_X
was any other bit.  ... and yes, once upon a time, something somewhere
in the kernel once did this, I forget what or where.

The only other thing of note is that many application programs do
really scary things with the casting of function pointers (usually
to do OO style programming in C, w/ upcasts/downcasts to change the
type of the arguments passed to a routine, or add additional arguments.)
I don't know that the kernel does this anywhere, though.  Maybe in
that kobject code :)


--linas

p.s. now that I have your attention, you once had some EEH questions/comments?

** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/