Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!uwvax!oddjob!gargoyle!ihnp4!homxb!whuts!mike
From: mike@whuts.UUCP (BALDWIN)
Newsgroups: comp.lang.c
Subject: Re: Weird syscall returns
Message-ID: <2439@whuts.UUCP>
Date: Fri, 17-Jul-87 16:08:56 EDT
Article-I.D.: whuts.2439
Posted: Fri Jul 17 16:08:56 1987
Date-Received: Sat, 18-Jul-87 17:22:44 EDT
References: <1158@copper.TEK.COM> <6858@auspyr.UUCP> <17171@cca.CCA.COM> <1641@sfsup.UUCP>
Organization: AT&T Bell Laboratories
Lines: 25
Summary: remember nice and fcntl

In article <1641@sfsup.UUCP>, mpl@sfsup.UUCP (M.P.Lindner) writes:
> So, what call returns a -1 as an error that can also return a negative
> integer as a valid value?  NONE!

Sorry, but you've misclassified nice(2).  It returns the new nice value
(range 0-39) minus 20.  Thus, it can return anything in the range -20 to
19 on SUCCESSFUL completion.

>                                           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.

I claim it is more natural and correct to test for whatever the manual
page says.  E.g., fcntl(2) DIAGNOSTICS in SVR3.0 says for most cmds taht
the successful completion return is "Value other than -1."  Therefore, if
you code it as "if (fcntl() < 0)" then you are NOT PORTABLE, because nothing
guarantees that it won't return -2 on success in the future.

For a great many system calls, it doesn't matter currently.  But why make
it more difficult in the future if something changes in a way that's
compatible with the docs but not with your code?
-- 
Michael Scott Baldwin		{at&t}!whuts!mike	I only speak
AT&T Bell Laboratories		+1 201 386 3052		for myself!