[lkml]   [2004]   [Sep]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 8/10] Re: [2.6-BK-URL] NTFS: 2.1.19 sparse annotation, cleanups and a bugfix

On Sat, 25 Sep 2004 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)

- 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 {

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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2009-11-18 23:46    [W:0.070 / U:4.116 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site