DragonFly BSD
DragonFly commits List (threaded) for 2004-12
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: cvs commit: src/usr.bin/newgrp


From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
Date: Mon, 13 Dec 2004 01:51:43 -0800 (PST)

:> Is it? I always found == -1 to be rather straightforward, and 
:> considering (according to SUSv3) that setenv _must_ return only 0 or -1, 
:> I see no point to check for any other value. If setenv were to return 
:...
:> 
:> Devon H. O'Dell
:
:Alot of the code that I have seen uses the < 0 idiom.  Negative numbers
:are commonly used to indicate error, but in most cases it just dosen't
:matter which error has occured.  Testing of == indicates to me that
:you are testing for a spacific error.  But doing that slows down my
:reading of the code since now I have to see which other errors might
:be returned.  Yes you know that setenv() and alot of other functions
:return only -1, but some return other negative numbers.  So now I have
:to go check if setenv() returns other errors.
:
:Using < 0 tells me that if any error value is returned, handle it here.
:
:					Max

    Yah, that's my take too... It's psychological.  I find that it is easier
    to read code that does a blanket < 0 check verses code that explicitly
    tests for -1.  It isn't just the libc or syscall API, either... one must
    consider that the code one is reading is making all sorts of procedure
    calls to all sorts of different places which may or may not return only
    -1 on error.  So checking for < 0 makes the code more uniform, and 
    easier to read in that respect as well.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]