Date: Thu, 22 Oct 1998 09:20:14 -0700 (PDT) From: Archie Cobbs <archie@whistle.com> To: eischen@vigrid.com (Daniel Eischen) Cc: current@FreeBSD.ORG, lists@tar.com Subject: Re: Another Serious libc_r problem Message-ID: <199810221620.JAA01628@bubba.whistle.com> In-Reply-To: <199810220106.VAA07017@pcnet1.pcnet.com> from Daniel Eischen at "Oct 21, 98 09:06:18 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Daniel Eischen writes: > > > > I would argue that for any case that POSIX says results in "undefined > > > > behavior", and the pthread code can easily detect this case, FreeBSD > > > > should immediately abort(3). Threads programmers will thank you > > > > when their bugs are revealed for them. > > > > > > If it's like pthread_mutex_lock(), POSIX will say that pthread_cond_wait > > > should return EINVAL if it doesn't own the mutex *and* this condition > > > is detected by the implementation. Much as we'd like to say "Bad > > > programmer, Bad!" I don't think POSIX will allow us to with anything > > > other than an EINVAL return value. > > > > What you've described looks like *defined* behavior to me... > > Well, that's what the POSIX spec says. If you are going to > detect the condition, then you must return EINVAL. If you > are not going to detect the condition, then "undefined > behavior" occurs. So, then it's kindof like an honor system :-) who's to know when you've "detected" it? Anyway, I conceed. Modify the original idea with the phrase "when not in conflict with the spec"... -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199810221620.JAA01628>