From: Matthew Wilcox <willy@infradead.org>
To: Lennart Poettering <lennart@poettering.net>
Cc: NeilBrown <neilb@suse.com>,
"Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>,
linux-man@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH man-pages] open.2: improve O_PATH documentation.
Date: Thu, 10 Aug 2017 08:50:34 -0700 [thread overview]
Message-ID: <20170810155034.GH31390@bombadil.infradead.org> (raw)
In-Reply-To: <20170810102104.GA16888@gardel-login>
On Thu, Aug 10, 2017 at 12:21:04PM +0200, Lennart Poettering wrote:
> On Do, 10.08.17 13:25, NeilBrown (neilb@suse.com) wrote:
> > +.RB ( ".f_type == AUTOFS_SUPER_MAGIC" ).
>
> Because Linux is broken you shouldn't compare f_type just like this,
> and the man page probably shouldn't suggest that either I figure. The
> only safe way is something like this:
>
> s.f_type == (typeof(s.f_type)) AUTOFS_SUPER_MAGIC
>
> That's because f_type is defined with different types (both signed and
> unsigned) on different archs, and the magic values tend to use the
> full unsigned 32bit range...
Please give an example where Neil's formulation would fail.
$ git grep -w f_type arch/*/include |cut -d: -f 2- |sort -u
int f_type;
long f_type;
s32 f_type;
__u32 f_type;
u32 f_type;
unsigned int f_type;
I quote the C standard here for your convenience:
Otherwise, the integer promotions are performed on both operands.
Then the following rules are applied to the promoted operands:
If both operands have the same type, then no further conversion is needed.
Otherwise, if both operands have signed integer types or both have unsigned
integer types, the operand with the type of lesser integer
conversion rank is converted to the type of the operand with greater rank.
Otherwise, if the operand that has unsigned integer type has rank
greater or equal to the rank of the type of the other operand,
then the operand with signed integer type is converted to the type
of the operand with unsigned integer type.
Otherwise, if the type of the operand with signed integer type can represent
all of the values of the type of the operand with unsigned integer type, then
the operand with unsigned integer type is converted to the type of
the operand with signed integer type.
Otherwise, both operands are converted to the unsigned integer
type corresponding to the type of the operand with signed integer type
> (Yes, strictly speaking AUTOFS_SUPER_MAGIC isn't one of the unsigned
> 32bit ones, but I think it's better to stick the same rules for all
> magic values comparisons here...)
>
> (And yes, the statfs() man page only mentions the problem briefly,
> without the typeof way out, but it really should)
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
next prev parent reply other threads:[~2017-08-10 15:50 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-10 3:25 [PATCH man-pages] open.2: improve O_PATH documentation NeilBrown
2017-08-10 10:21 ` Lennart Poettering
2017-08-10 14:02 ` Krzysztof Błaszkowski
2017-08-10 23:04 ` NeilBrown
2017-08-12 20:13 ` Michael Kerrisk (man-pages)
2017-08-10 15:50 ` Matthew Wilcox [this message]
2017-08-12 20:11 ` Michael Kerrisk (man-pages)
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=20170810155034.GH31390@bombadil.infradead.org \
--to=willy@infradead.org \
--cc=lennart@poettering.net \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-man@vger.kernel.org \
--cc=mtk.manpages@gmail.com \
--cc=neilb@suse.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).