This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH v2] [BZ #10283] localedef: align fixed maps to SHMLBA


> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]