Re: glibc 2.21 - Machine maintainers, please test your machines.

[Andreas Schwab <schwab at suse dot de>]

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.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."