From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Andreas Dilger <adilger@dilger.ca>
Cc: Ext4 Developers List <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH] ext4: avoid declaring fs inconsistent due to invalid file handles
Date: Tue, 18 Dec 2018 11:35:39 -0500 [thread overview]
Message-ID: <20181218163539.GC25775@mit.edu> (raw)
In-Reply-To: <F169A778-5219-4FDD-8899-3074DFFDD8A4@dilger.ca>
On Mon, Dec 17, 2018 at 10:43:40PM -0700, Andreas Dilger wrote:
> I don't think that it is verboten to use binary flag values in an enum,
> if you explicitly specify the values, which is why I used "0x01", "0x02"
> to make it more clear these are binary values. IMHO, using a named enum
> is a good way to annotate the function parameters rather than a generic
> "int flag" parameter that is ambiguous unless you look at the function
> code to see what the values of "flag" might be.
I tend to only use enums in this kind of way:
enum classification_levels {
FOR_OFFICIAL_USE_ONLY,
CONFIDENTIAL,
SECRET,
TOP_SECRET,
};
I think the reason why I've never used it for type checking is because
for gcc and sparse, it doesn't work. For the below example, "gcc
-Wall foo.c" won't complain at all. Sparse complains only about the
"return a | b;" line, because we're combining two different enum
types. Sparse doesn't say boo that I passed EXT4_IGET_NORMAL where a
classification_levels, and secret where an ext4_iget_flags is
expected:
enum ext4_iget_flags {
EXT4_IGET_RESERVED = 0x00, /* just guessing, see further below */
EXT4_IGET_NORMAL = 0x01,
EXT4_IGET_HANDLE = 0x02
};
int combine(enum classification_levels a, enum ext4_iget_flags b)
{
return a | b;
}
int main(int argc, char **argv)
{
printf("%d\n", combine(EXT4_IGET_NORMAL, secret));
exit(1);
}
Then again, llvm does correctly complain, and at least for Android
configs, llvm will complain kernels correctly (although I'm not sure
enterprise distros trust LLVM just yet), and I do agree that it's
useful from a documentation perspective.
Cheers,
- Ted
next prev parent reply other threads:[~2018-12-18 16:43 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-13 17:51 [PATCH] ext4: avoid declaring fs inconsistent due to invalid file handles Theodore Ts'o
2018-12-17 22:53 ` Andreas Dilger
2018-12-18 4:45 ` Theodore Y. Ts'o
2018-12-18 5:43 ` Andreas Dilger
2018-12-18 16:35 ` Theodore Y. Ts'o [this message]
2018-12-19 17:31 ` [PATCH -v2] " Theodore Ts'o
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=20181218163539.GC25775@mit.edu \
--to=tytso@mit.edu \
--cc=adilger@dilger.ca \
--cc=linux-ext4@vger.kernel.org \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.