Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!mcnc!gatech!bloom-beacon!think!ames!oliveb!sun!gorodish!guy
From: guy%gorodish@Sun.COM (Guy Harris)
Newsgroups: comp.lang.c,comp.unix.questions
Subject: Re: Weird syscall returns
Message-ID: <23743@sun.uucp>
Date: Fri, 17-Jul-87 14:20:19 EDT
Article-I.D.: sun.23743
Posted: Fri Jul 17 14:20:19 1987
Date-Received: Sat, 18-Jul-87 16:47:40 EDT
References: <1158@copper.TEK.COM> <6858@auspyr.UUCP> <17171@cca.CCA.COM> <1641@sfsup.UUCP>
Sender: news@sun.uucp
Followup-To: comp.unix.questions
Lines: 24
Xref: mnetor comp.lang.c:3126 comp.unix.questions:3228

> Whoa there, let's take a look:
> return code		sys call
> non-negative int or -1	creat, dup, fork, lseek, msgget, nice, open,
> 
> So, what call returns a -1 as an error that can also return a negative
> integer as a valid value?  NONE!  I know about maus, but since we're
> talking portable, don't even mention it.  My claim is that since *most*
> of the system calls return n >= 0 on success, it is more natural to test
> for !(n >= 0) which is the same as n < 0 for failure.

Whoa there, let's take a *careful* look this time.  "nice" *can* return a
negative integer ("Upon successful completion, 'nice' returns the new nice
value minus 20," from the S5R2 manual page, and the new "nice" value
can be less than 20).  It is OK to test for "n < 0" if the call is
guaranteed to return a non-negative integer on success, but NOT if it
can return a negative integer.

"nice" is even worse, because (at least on systems where it returns
the new "nice" value) it can return -1 on *success*!  You can only
test this by clearing "errno", making the call, and testing "errno"
after the call.  (The same is true of "ptrace".)
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com