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