This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: For review: nptl(7) man page
- From: Roland McGrath <roland at hack dot frob dot com>
- To: Rich Felker <dalias at libc dot org>
- Cc: Torvald Riegel <triegel at redhat dot com>, "Michael Kerrisk (man-pages)" <mtk dot manpages at gmail dot com>, Nicholas Miell <nmiell at gmail dot com>, linux-man at vger dot kernel dot org, libc-alpha at sourceware dot org, Carlos O'Donell <carlos at redhat dot com>
- Date: Tue, 4 Aug 2015 08:06:48 -0700 (PDT)
- Subject: Re: For review: nptl(7) man page
- Authentication-results: sourceware.org; auth=none
- References: <550ED3F4 dot 1080403 at gmail dot com> <550F363B dot 801 at gmail dot com> <55B1EFFA dot 9070608 at gmail dot com> <CAODz2cDq4o85NOzqCDg9cH8eCvqt3Tq5QXKMMJtXbik5h5bL+Q at mail dot gmail dot com> <55B54215 dot 6070502 at gmail dot com> <1438616740 dot 20974 dot 81 dot camel at localhost dot localdomain> <20150803200825 dot GJ16376 at brightrain dot aerifal dot cx>
> It doesn't directly. If you consider the models as two separate
> "compilation environments"/"execution environments" of the same
> implementation, then it would at least be within the scope of POSIX to
> have something to say about it.
I think we are asserting that they are exactly that by dint of the confstr
results for _CS_POSIX_V7_ILP32_OFF32_CFLAGS et al. So the question is what
POSIX actually does or doesn't say about process-shared synchronization
objects being shared between processes running programs built in different
POSIX compilation environments.
The other relevant question is whether 32/64 sharing of each particular
pshared object has in fact worked reliably under glibc in the past. Since
we haven't been clear and explicit about the subject before AFAIK, then if
in fact it worked before then people might well have inferred that we made
such an ABI guarantee. (I hope not, since if so we just broke it.)