From owner-freebsd-current Wed Oct 21 18:08:05 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA07074 for freebsd-current-outgoing; Wed, 21 Oct 1998 18:08:05 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA07067 for ; Wed, 21 Oct 1998 18:08:01 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id VAA07017; Wed, 21 Oct 1998 21:06:18 -0400 (EDT) Date: Wed, 21 Oct 1998 21:06:18 -0400 (EDT) From: Daniel Eischen Message-Id: <199810220106.VAA07017@pcnet1.pcnet.com> To: archie@whistle.com, eischen@vigrid.com Subject: Re: Another Serious libc_r problem Cc: current@FreeBSD.ORG, lists@tar.com Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Daniel Eischen writes: > > > Random interjected comment.. > > > > > > 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. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message