Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!lll-lcc!lll-tis!ptsfa!ihnp4!homxb!mhuxt!mhuxm!mhuxo!ulysses!sfmag!sfsup!mpl
From: mpl@sfsup.UUCP (M.P.Lindner)
Newsgroups: comp.lang.c
Subject: Re: Weird syscall returns
Message-ID: <1641@sfsup.UUCP>
Date: Thu, 16-Jul-87 17:33:48 EDT
Article-I.D.: sfsup.1641
Posted: Thu Jul 16 17:33:48 1987
Date-Received: Sat, 18-Jul-87 13:04:58 EDT
References: <1158@copper.TEK.COM> <6858@auspyr.UUCP> <17171@cca.CCA.COM> <2337@whuts.UUCP>
Organization: AT&T-IS, Summit N.J. USA
Lines: 33
Summary: why not 0, then

In article <2337@whuts.UUCP>, mike@whuts.UUCP writes:
> In article <1219@ius2.cs.cmu.edu>, edw@ius2.cs.cmu.edu (Eddie Wyatt) writes:
> ] > Almost agreed: but if a negative return code other than -1 is returned
> } > the code doesn't react the same.
> 
> True, and the man pages are all very explicit.  The DIAGNOSTICS section
> of (almost) every one contains the sentence, "Otherwise, a value of -1 is
> returned and errno is set to indicate the error."  The man page *only*
> guarantees -1, so why write potentially unportable code when it is so
> *trivial* to make it correct?  It is _not_ just a style issue.
> -- 

Whoa there, let's take a look:
return code		sys call
0 or -1			access, acct, brk, chdir, chmod, chown, chroot, close,
			kill, link, mknod, mount, msgctl, pipe, plock, setuid,
			setgid, shmctl, stat, stime, umount, unlink, ustat,
			utime
non-negative int or -1	creat, dup, fork, lseek, msgget, nice, open,
			read, semget, shmget, time, times, ulimit, umask,
			uname, wait, write
bad things		sbrk, signal, semop, shmop, msgop
ha ha			exit, exec, pause, sync
can't tell from man	getpid, getuid, ioctl, profil, ptrace, semctl, setpgrp
or no error code	alarm, fcntl

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.

Therefore, testing for < 0 is _not_ incorrect.  It _is_ a style issue.