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.