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)