Return to BSD News archive
Newsgroups: comp.os.386bsd.bugs
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!howland.reston.ans.net!zaphod.mps.ohio-state.edu!uwm.edu!caen!hellgate.utah.edu!fcom.cc.utah.edu!cs.weber.edu!terry
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: cvs 1.3 bugfix
Message-ID: <1993Mar15.215218.9502@fcom.cc.utah.edu>
Sender: news@fcom.cc.utah.edu
Organization: Weber State University (Ogden, UT)
References: <blwf{4xU@twinsun.com> <1993Mar9.220333.11842@fcom.cc.utah.edu> <blzf!oQi@twinsun.com>
Date: Mon, 15 Mar 93 21:52:18 GMT
Lines: 59
In article <blzf!oQi@twinsun.com> eggert@twinsun.com (Paul Eggert) writes:
>terry@cs.weber.edu (Terry Lambert) writes:
>
> eggert@twinsun.com (Paul Eggert) writes:
>
> In some places, Posix requires that errors *must* be
> detected. For example, 5.1.2.4 says that opendir()
> must detect and report EACCES-style errors. (By
> ``report'' I mean ``yield -1 and set errno''.) But in
> other places, Posix merely says that *if* an error is
> detected, *then* it must be reported. This is the case
> for sigismember and EINVAL-style errors.
>
> This is bogus; this reading implies that:
>
> 3.3.3.3 Returns
>
> Upon successful completion, the sigismember() function returns
> a value of one if the specified signal is a member of a
> specified set, or a value of zero if it is not. Upon
> successful completion, the other functions return a value of
> zero. For all of the above functions, if an error is detected,
> a value of -1 is returned, and _errno_ is set to indicate the
> error.
>
> Can fail to successfully complete (thus not returning 0), but have the
> error which caused it to fail to complete reamin undetected (thus not
> returning -1).
>
>That scenario is impossible. It's prohibited by the following crucial
>sentence in section 2.4: ``If no error condition is detected,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>the action requested shall be successful.''
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The question is whether "detected" is the same as "occurs". The reading
of 2.4 you suggest implies that they must be the same, otherwise the
action will not be successful.
If this is truly the case, then we should check for out-of-range and
non-contiguous signal groups, per the first patch.
If this is not the case, someone needs to make up a story as to how a
successful action can result in undefined behaviour.
So does someone make up a story, or do we all apply the patch?
Terry Lambert
terry@icarus.weber.edu
terry_lambert@novell.com
---
Any opinions in this posting are my own and not those of my present
or previous employers.
--
-------------------------------------------------------------------------------
"I have an 8 user poetic license" - me
Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
-------------------------------------------------------------------------------