glibc 2.21 - Machine maintainers, please test your machines.

[Torvald Riegel]

On Tue, 2015-01-27 at 11:59 +0100, Andreas Schwab wrote:
> Torvald Riegel <triegel@redhat.com> writes:
> 
> > On Mon, 2015-01-26 at 23:56 +0100, Andreas Schwab wrote:
> >> Torvald Riegel <triegel@redhat.com> writes:
> >> 
> >> > I don't think so, because in a badly 4B-aligned (ie, no 8B-aligned) use,
> >> > struct new_sem is at offset 4 of the semaphore.  If you copy that to a
> >> > 8B-aligned semaphore just bit-by-bit, then the actual data will still
> >> > start at offset 4, but to_new_sem will assume offset 0.
> >> 
> >> It is undefined to use a copy of a sem_t in any of the semaphore calls.
> >
> > I think we all agree on that.  Nonetheless, as I mentioned previously,
> > I'm not actually aware of where in POSIX (or C?) this would be
> > explicitly forbidden.  So if you know that, I'd be interested in getting
> > a reference.
> 
> See sem_init.
> 
>     Only sem itself may be used for performing synchronization. The
>     result of referring to copies of sem in calls to sem_wait(),
>     sem_timedwait(), sem_trywait(), sem_post(), and sem_destroy() is
>     undefined.

Hmm, that was obvious.  Thanks for pointing it out :)