Re: [PATCH 8/10] Re: [2.6-BK-URL] NTFS: 2.1.19 sparse annotation, cleanups and a bugfix

[Linus Torvalds <torvalds@osdl.org>]

On Sat, 25 Sep 2004 viro@parcelfarce.linux.theplanet.co.uk wrote:
> 
> Linus, backing store is irrelevant here (and BTW, variables are no better
> or worse than arguments / structure fields / return values / argument of
> sizeof / etc.)

I agree that in the case of NTFS it is irrelevant. I was talking more in 
general: if you use enums with "types", you really should only use them as 
compile-time constants. Which is, obviously, one very common usage of 
enums, but is not the only one.

I personally believe that people use enum's largely in two (independent) 
ways:

 - a convenient compile-time constant:

	enum {
		DevEnableMask = 1UL << 0,
		DevIRQMask = 1UL << 5,
		DevError = 1UL << 31
	};

   where you never actually _save_ an enum anywhere. In this case, the 
   typing is very convenient indeed.

 - a "type enumerator":

	enum token_type {
		TOKEN_IDENT = 1,
		TOKEN_NUMBER,
		TOKEN_MACRO,
	...

   where the enum actually is used as a variable to distinguish different 
   cases. In this case, the per-enum typing ends up being possibly even 
   confusing, since using a constant will have a potentially _different_ 
   type than loading that constant from a variable.

The second case is why I think it's a sane thing to warn if anybody ever 
creates a variable (or structure/union member) with an enum that used the 
typing features. Not because we can't make the enum fit all the values, 
but because the types simply WILL NOT MATCH. They fundamentally cannot, 
since we took the approach of having per-entry types.

And for sparse, since the type is _the_ most important part of anything, 
we should warn when the types won't match.

		Linus