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!