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