Complexity of reallocating storage (was users command crap)

[Michael John Muuss <mike>]

In article <14994:Feb207:10:4791 at kramden.acf.nyu.edu>,
brnstnd at kramden.acf.nyu.edu (Dan Bernstein) writes:
|> Are you worried about all the ignored return codes? I'll go through them
|> one by one. Sure, I could've programmed more defensively, but the only
|> possible response to a fatal error would be cutting off the user program
|> from its input and output.
|>
|> Cannot fail.
|> Guaranteed to work, as above.
|> Ditto.
|> 
|> ---Dan

Dear Dan -

I have seen every one of the system-calls you claim as "guaranteed to
work" FAIL, in similar usage.  (I've seen sprintf() fail too, but
checking it's return code is problematic, due to the differences between
BSD and SYSV implementations, so portability usually wins here).
Filesystems filling up, memory failures, failing disk drives, corrupted
program memory images, NFS outages and server malfunctions, etc, etc.
".." can unexpectedly vanish, or take you to unexpected places.  ".."
may not even be of type=directory! In my 17 years of using UNIX, I've
seen it all.  Not often, but not "never".

   "The problem with making programs foolproof is that the fools are so
    damned clever!"  That goes double for hardware.

Having programs not checking the error returns can make the job of
troubleshooting and repairing malfunctions much more difficult.
Yes, error checking can demand 3-4 times as much code as the actual
task at hand.  For essential systems programs, and criticial user
applications, the error checking is well worth it.

I don't think that I would consider the application under discussion
"critical", so your (void)ing the error returns in this application was
entirely appropriate. But, I didn't want you (or other readers of this
list) to think that the sys-calls which you considered "guaranteed" to
work actually would be, under all circumstances.  They are not.

	Best,
	 -Mike Muuss

	  Advanced Computer Systems
	  Ballistic Research Laboratory
	  APG, MD  21005-5066