This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v2] [BZ #10283] localedef: align fixed maps to SHMLBA
- From: Roland McGrath <roland at hack dot frob dot com>
- To: "Carlos O'Donell" <carlos at redhat dot com>
- Cc: David Miller <davem at davemloft dot net>, vapier at gentoo dot org, libc-alpha at sourceware dot org
- Date: Wed, 29 May 2013 16:18:38 -0700 (PDT)
- Subject: Re: [PATCH v2] [BZ #10283] localedef: align fixed maps to SHMLBA
- References: <20130528194042 dot 1EF7B2C074 at topped-with-meat dot com> <20130528 dot 130721 dot 1721261559877509450 dot davem at davemloft dot net> <51A51186 dot 7070904 at redhat dot com> <20130528 dot 132601 dot 2200516495498570890 dot davem at davemloft dot net> <51A524FE dot 7040202 at redhat dot com> <20130528231403 dot 2C6C32C05D at topped-with-meat dot com> <51A544A5 dot 5050001 at redhat dot com> <20130529000346 dot 0D6AB2C073 at topped-with-meat dot com> <51A549FB dot 1010402 at redhat dot com>
> Your interpretation is more strict than mine.
I really don't think this is a question of "strictness". You (and Mike)
are perceiving ambiguity where there just isn't any. But the mere fact
that reasonable people could misinterpret the text this way is reason
enough to recommend to the committee that they rephrase those passages so
this mistake is much harder to make.
> I do not interpret it that strictly and I think language in
> other parts of the standard backs up that interpretation.
It really doesn't. You are misinterpreting the other uses.
> The text in other parts of the standard uses the same language
> of "multiple of" to indicate you get an alignment of "something"
> or better.
>
> e.g. From post_memalign:
> ~~~
> Upon successful completion, the value pointed to by memptr
> shall be a multiple of alignment.
For addresses, "be a multiple of X" and "be aligned to X" mean exactly the
same thing. 16384 is a multiple of 4096. Hence the address 16384 is a
multiple of 4096. The fact that 16384 is also a multiple of 8192 is
irrelevant.
> Thus my reading of the above is that it says "the implementation may
> require that addr be aligned to page size or better."
It's just utterly clear to me that this is not what that paragraph means.
I don't know how to explain it further without attempting to teach English.
But, as Andreas pointed out, it turns out that interpreting that paragraph
is not actually required to answer our real question. It's made quite
clear by:
The mmap() function may fail if:
[EINVAL]
The addr argument (if MAP_FIXED was specified) or off is not a
multiple of the page size as returned by sysconf(), or is
considered invalid by the implementation.
The "considered invalid by the implementation" clause gives a free hand
here. It really means that a conforming application cannot use MAP_FIXED
at all (with the expectation that it will necessarily work), or perhaps can
use it only with an address delivered by a prior mmap call (with an offset
that worked in that earlier call). This being the case, it would be
helpful if the committee amended the main MAP_FIXED paragraph to be more
explicit about the constraints. In fact, to make MAP_FIXED as specified be
useful for anything other than overwriting an existing mapping, it would
IMHO be best if this were specified as implementation-defined--meaning that
the conformance document must describe the constraints on address values
for use with MAP_FIXED, which the "considered invalid" wording does not
require.
Thanks,
Roland