Return to BSD News archive
Newsgroups: comp.os.386bsd.bugs
Path: sserve!manuel.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!cs.utexas.edu!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: <1993Mar9.220333.11842@fcom.cc.utah.edu>
Sender: news@fcom.cc.utah.edu
Organization: Weber State University (Ogden, UT)
References: <blv0K2^8@twinsun.com> <RICH.93Mar6233047@omicron.Rice.edu> <blwf{4xU@twinsun.com>
Date: Tue, 9 Mar 93 22:03:33 GMT
Lines: 72
In article <blwf{4xU@twinsun.com> eggert@twinsun.com (Paul Eggert) writes:
>rich@Rice.edu (Richard Murphey) writes:
>
>>In article <blv0K2^8@twinsun.com> eggert@twinsun.com (Paul Eggert) writes:
>
>> Posix 3.3.3.3 says that the sigismember macro must behave as follows.
>
>> IF sigismember(N,S) completes successfully
>> THEN it yields 1 if signal N is a member of the set S, 0 otherwise
>> ELSE it yields -1 and sets errno
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>>??? It says '...if an error is *detected*, a value of -1 is
>>returned...' as you quoted below. Does 'is detected' mean the same
>>thing as 'occurred' here?
>
>It doesn't matter whether the error occurs, only whether it is detected.
>(In this case, the ``error'' is sigismember(N,S) where N is out of range.)
>There is some implementation freedom here, namely whether to detect the error.
>If the error is detected, then sigismember must yield -1 and set errno;
>otherwise, sigismember must yield the correct answer, which is 0 in this case.
>
>
>>Why doesn't the standard use 'occurs' here as it does in other sections
>>(e.g. 5.1.2.4) rather than 'is detected'?
>
>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).
By this argument, the behaviour is allowed to be undefined. Not only is
this unacceptable from the user's standpoint, since it isn't a defined
interface if some behaviour is undefined, it also, frankly, sucks.
My opinion is that this *requires* a change in interpretation to make
either "is detected" read "occurs" or it *requires* the addition of another
return value. To my mind "undefined" is a useless state and should not be
allowed by the interface.
POSIX 1003.1 is an interface >*definition*<. If we choose to confrom to
it, it ought to be usable as well as implementable.
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
-------------------------------------------------------------------------------