linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).