Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!rochester!pt!ius1.cs.cmu.edu!edw From: edw@ius1.cs.cmu.edu (Eddie Wyatt) Newsgroups: comp.lang.c Subject: Re: Weird syscall returns Message-ID: <1016@ius1.cs.cmu.edu> Date: Fri, 17-Jul-87 09:53:36 EDT Article-I.D.: ius1.1016 Posted: Fri Jul 17 09:53:36 1987 Date-Received: Sat, 18-Jul-87 13:48:56 EDT References: <1158@copper.TEK.COM> <6858@auspyr.UUCP> <17171@cca.CCA.COM> <1641@sfsup.UUCP> Organization: Carnegie-Mellon University, CS/RI Lines: 70 In article <1641@sfsup.UUCP>, mpl@sfsup.UUCP (M.P.Lindner) writes: > 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. > > -- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ These aren't my comments, please don't credit them to me. Give the proper credit to who ever wrote them. > > 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. As others have pointed out, there are a few obsure Unix system calls that will return an negetive number on success (dismaus, switmaus PDP-11, some implementations of nice, one networking primative which I forget its name). So its not totally a question of style. Neither is a total question of correctness. If your read or write calls are returning negative bytes read or written then somethings has gone wrong. There are a few widely used systems calls which return values are /should be/ understood - examples read, write, open ... In case as such, the issue of == -1 vs. < 0 becomes a style issue. I like to diverge a minute to the signal system call. I think this is a good example of bad interface design. By intermixing return value with error status information, one has created a sloppy interface with incompatible return types (int and int (*func)()). In general, the interface to any system call should only return status information and modify input parameters to return values. If this where the case, there would be no need for errno and no more sloppy interfaces like signal. The type of the error could be return as an indication of an error with one value reserved to indicate success. This method has been the the approach MACH has taken. -- Eddie Wyatt e-mail: edw@ius1.cs.cmu.edu