Re: ANSI-fy of ranlib, ruptime and rdist [patches]

:Also, while not checking a return value is usually not the cause of a 
:bug, it can often provide very useful clues for the onset of a bug. 
:I've had people complain, for example, that an IPC library I wrote isn't 
:working properly, or that it's causing a coredump.  Upon closer 
:inspection, they were ignoring the fact that an xxxConnect() call was 
:returning ECONNREFUSED.
:
:Maybe we just have sloppier programmers at work? <shrug>

    Yes, but the problem is that 99.9% of the time the cases where one
    isn't checking the return value are, in fact, not bugs.  By imposing
    a rule which requires code handling of a return value every single
    time, you create a situation where 99.9% of the code that otherwise
    could simply ignore the return value must now explicitly handle it in
    some way.  With enough of these rules the code basically turns into an
    unreadable mess, where most of the code is handling language requirements
    rather then implementing the algorithm, and the meat is so obscured that
    even a good programmer (other then the one who wrote it) would not be
    able to follow or understand what the code is actually trying to do.

    There is only one way to write a good program, and that is to be a good
    programmer.  It is absurdly easy to write Java or C++ or Eiffel that
    adheres to all the requirements but is still full of bugs and utterly
    incomprehensible to everyone else.  In some respects, the class hierarchy
    actually makes it worse, though I personally like the idea of classes (as
    long as they aren't abstracted out to obscene levels).  The idea of
    language-enforced bug detection through complete formalization of all
    variable and procedural interactions doesn't work in practice.

					-Matt
					Matthew Dillon 
					<[e-mail]>