LKML Archive on lore.kernel.org
 help / color / Atom feed
From: Linus Torvalds <torvalds@osdl.org>
To: viro@parcelfarce.linux.theplanet.co.uk
Cc: Anton Altaparmakov <aia21@cam.ac.uk>,
	Andrew Morton <akpm@osdl.org>,
	linux-kernel@vger.kernel.org,
	linux-ntfs-dev@lists.sourceforge.net
Subject: Re: [PATCH 8/10] Re: [2.6-BK-URL] NTFS: 2.1.19 sparse annotation, cleanups and a bugfix
Date: Sat, 25 Sep 2004 08:43:17 -0700 (PDT)
Message-ID: <Pine.LNX.4.58.0409250834110.2317@ppc970.osdl.org> (raw)
In-Reply-To: <20040925072516.GS23987@parcelfarce.linux.theplanet.co.uk>



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

  reply index

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-24 16:11 Anton Altaparmakov
2004-09-24 16:12 ` [PATCH 1/10] " Anton Altaparmakov
2004-09-24 16:12   ` [PATCH 2/10] " Anton Altaparmakov
2004-09-24 16:13     ` [PATCH 3/10] " Anton Altaparmakov
2004-09-24 16:13       ` [PATCH 4/10] " Anton Altaparmakov
2004-09-24 16:13         ` [PATCH 5/10] " Anton Altaparmakov
2004-09-24 16:13           ` [PATCH 6/10] " Anton Altaparmakov
2004-09-24 16:14             ` [PATCH 7/10] " Anton Altaparmakov
2004-09-24 16:14               ` [PATCH 8/10] " Anton Altaparmakov
2004-09-24 16:15                 ` [PATCH 9/10] " Anton Altaparmakov
2004-09-24 16:15                   ` [PATCH 10/10] " Anton Altaparmakov
2004-09-24 16:30                 ` [PATCH 8/10] " Linus Torvalds
2004-09-24 20:02                   ` Anton Altaparmakov
2004-09-25  2:46                     ` Linus Torvalds
2004-09-25  7:25                       ` viro
2004-09-25 15:43                         ` Linus Torvalds [this message]
2004-09-26  7:48                           ` Anton Altaparmakov
2004-09-26 16:39                             ` Linus Torvalds
2004-09-26  7:47                       ` Anton Altaparmakov
2004-09-26  7:51                         ` Anton Altaparmakov
2004-09-25  6:38               ` [PATCH 7/10] " viro
2004-09-25 23:31                 ` Anton Altaparmakov
2004-09-25  6:35             ` [PATCH 6/10] " viro
2004-09-25 23:09               ` Anton Altaparmakov
2004-09-26  0:10                 ` Anton Altaparmakov
2004-09-25  6:32         ` [PATCH 4/10] " viro
2004-09-26  0:06           ` Anton Altaparmakov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.58.0409250834110.2317@ppc970.osdl.org \
    --to=torvalds@osdl.org \
    --cc=aia21@cam.ac.uk \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-ntfs-dev@lists.sourceforge.net \
    --cc=viro@parcelfarce.linux.theplanet.co.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

LKML Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/lkml/0 lkml/git/0.git
	git clone --mirror https://lore.kernel.org/lkml/1 lkml/git/1.git
	git clone --mirror https://lore.kernel.org/lkml/2 lkml/git/2.git
	git clone --mirror https://lore.kernel.org/lkml/3 lkml/git/3.git
	git clone --mirror https://lore.kernel.org/lkml/4 lkml/git/4.git
	git clone --mirror https://lore.kernel.org/lkml/5 lkml/git/5.git
	git clone --mirror https://lore.kernel.org/lkml/6 lkml/git/6.git
	git clone --mirror https://lore.kernel.org/lkml/7 lkml/git/7.git
	git clone --mirror https://lore.kernel.org/lkml/8 lkml/git/8.git
	git clone --mirror https://lore.kernel.org/lkml/9 lkml/git/9.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 lkml lkml/ https://lore.kernel.org/lkml \
		linux-kernel@vger.kernel.org
	public-inbox-index lkml

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git