"sparse" warnings..

[linas at austin.ibm.com]

On Mon, May 03, 2004 at 06:23:25PM -0700, Linus Torvalds wrote:
>
> It's really hard to get mistakes like that on anything but "int" boundary.
> You'd never see it on a short, since constants are always at least "int"

I think you misread the example :)  The problem was not with the
constant, it was with the variable:  using a signed short for a bitflag.
Or, more precisely, using a signed short for a bitflag, setting
the 15th bit, and then using it somewhere where it can get sign-extended.
(e.g. bad 32-bit i/o code).  The sign extension clobbers the high bits.

The general rule is then "if its used as a bitflag, it should be unsigned."

grep short  include/linux/* |grep flag | grep -v unsigned

shows a dozen potentially dangerous usages.

> 	enum colors {
> 		black,
> 		red,
> 		blue,
> 		green,
> 	};

> where it never basically makes any sense to treat the enum as an integer.
> So make the type be "__attribute__((nocast))".

That would work.  A stop-gap to help catch uninitalized usage is
setting up a non-zero start value:

 	enum colors {
 		black=1,
 		red,
 		blue,
 		green,
 	};

> eeh? Maybe, but that must have been long enough ago that I don't even
> remember what EEH stands for..

extended error handling, a way of reporting PCI bus errors that would
otherwise cause machine-checks.

--linas


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