Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!gatech!bloom-beacon!think!ames!amdahl!pyramid!prls!philabs!micomvax!musocs!mcgill-vision!mouse
From: mouse@mcgill-vision.UUCP (der Mouse)
Newsgroups: comp.lang.c,comp.unix.questions
Subject: Re: Writing readable code
Message-ID: <838@mcgill-vision.UUCP>
Date: Sat, 11-Jul-87 05:36:02 EDT
Article-I.D.: mcgill-v.838
Posted: Sat Jul 11 05:36:02 1987
Date-Received: Sat, 18-Jul-87 19:09:44 EDT
References: <1158@copper.TEK.COM> <6858@auspyr.UUCP> <17171@cca.CCA.COM> <1219@ius2.cs.cmu.edu>
Followup-To: comp.unix.questions
Organization: McGill University, Montreal
Lines: 22
Xref: mnetor comp.lang.c:3140 comp.unix.questions:3238

In article <1219@ius2.cs.cmu.edu>, edw@ius2.cs.cmu.edu (Eddie Wyatt) writes:
>>> [ stuff re syscall(...) < 0 versus syscall(...) == -1 ]
>> Almost agreed: but if a negative return code other than -1 is
>> returned the code doesn't react the same.
> I can think of no Unix system call that doesn't return -1 on error.
> So I would say that it's a pretty good bet that "if (call(...) < 0)"
> and "if (call(...) == -1)" will act the same in all cases.

( First point: this is drifting off of C and into UNIX, so I'm trying
  to move it to comp.unix.questions. )

Well, yes, all syscalls return -1 on error.  However, that is not to
say that none ever return negative values except for an error return of
-1.  In fact, I was surprised by this recently.  I was using lseek() on
/dev/kmem on a VAX, and it was (correctly) returning success values on
the order of 0x80020000, which were negative!  I had to check for -1
explicitly instead of my usual check for <0 (yes, I am in the <0 camp
as far as actual coding practice goes).

					der Mouse

				(mouse@mcgill-vision.uucp)