"sparse" warnings..

[Linus Torvalds]

On Mon, 3 May 2004 linas at austin.ibm.com wrote:
>
> > 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.

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"
in size. So in order to get strange behaviour, you'd have to first
explicitly cast it to a short and then (possibly impicitly) cast it to
something else.

No, the thing I was thinking of is for things like "pte_t" and for enums.
Ie things like

	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))".

(And if the above sounds like an unlikely thing to do, think of the
GFP_KERNEL flags, and the fact that a lot of people put them in the wrong
order for things like "kmalloc()". Making the GFP_KERNEL flag be an enum
type that must not be implicitly cast to anything else would automatically
warn if somebody used it in any other context).

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

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

		Linus

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