sem_init() fails (when used in a certain way)

Christopher Faylor cgf-use-the-mailinglist-please@cygwin.com
Wed Mar 30 19:20:00 GMT 2011


On Wed, Mar 30, 2011 at 04:31:32PM +0200, Corinna Vinschen wrote:
>On Mar 30 08:07, Eric Blake wrote:
>> On 03/30/2011 02:01 AM, Corinna Vinschen wrote:
>> > Thanks for clarifying.  We just have to keep in mind to return EINVAL
>> > rather than EFAULT.
>> > 
>> > Btw., glibc does not test the validity of the semaphore at all.  If you
>> > give an invalid sem pointer to the sem functions, it just crashes:
>> 
>> Which is allowed by POSIX.  In fact, my understanding is that older
>> POSIX used to require that invalid objects be identified, until Ulrich
>> argued that there are pathological cases (such as reuse of heap that
>> already contains contents from a prior pointer) that make such detection
>> practically impossible in any reasonable amount of time, so POSIX was
>> intentionally relaxed to no longer require detection of invalid objects
>> (they are just as undefined as any other use of a bad pointer) in order
>> to cater to glibc.
>
>So we could not add myfault handler's *and* remove the is_good_object
>tests everywhere and we would still be on the safe side of Linux and
>POSIX, right?  That would perhaps speed up extensive usage of the
>pthread functions noticably.

I believe FreeBSD works like this too if the number of bug reports my team
(the OS group) gets at NetApp are any indication.  People pass all manner
of crap to pthread code and think it's a libc bug when things crash.

cgf



More information about the Cygwin-developers mailing list