Xref: utzoo comp.bugs.4bsd:1742 comp.unix.programmer:1004
Path: utzoo!utgpu!watserv1!watmath!att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!usc!cs.utexas.edu!sun-barr!newstop!texsun!convex!news
From: tchrist@convex.COM (Tom Christiansen)
Newsgroups: comp.bugs.4bsd,comp.unix.programmer
Subject: Re: Complexity of reallocating storage (was users command crap)
Message-ID: <1991Feb07.013637.6542@convex.com>
Date: 7 Feb 91 01:36:37 GMT
References: <4702@goanna.cs.rmit.oz.au> <29421:Feb419:13:5891@kramden.acf.nyu.edu> <8921@sail.LABS.TEK.COM>
Sender: news@convex.com (news access account)
Reply-To: tchrist@convex.COM (Tom Christiansen)
Followup-To: comp.unix.programmer
Organization: CONVEX Software Development, Richardson, TX
Lines: 73
Nntp-Posting-Host: pixel.convex.com

From the keyboard of terryl@sail.LABS.TEK.COM:
:     There's nothing I hate more than programs that silently fail, because I
:can't tell WHY they failed. Even just a simple "I can't do this because of that"
:is preferable (like perror(filename)). At least I can say "Aha, over quota;
:better delete some files." Also, don't tell me "Cannot open file", even if file
:is a real live filename. Tell me WHY you can't open it.

Well, perror(filename) is far better than nothing, but there two major
problems:

    1) It's not enough information.
    2) Sometimes you have no stderr.

Regarding problem 1, I like to see error messages in this form:

    program: operations on object: reason

as in:
    
    my_prog: cannot creat /foo/bar: permission denied

The my_prog is especially important in programs in pipelines.  I once
grepped through all the system source (ok, it was BSD, but that doesn't
let the rest of the world off the hook) for things that said effectively:

    printf(stderr, "cannot open: %s\n", filename);

and was horrified and angered.  They all deserve fixing.

On problem #2, I think that if you have no stderr, (and even if you do
for system programs) you should also syslog the problem.  It's not a
perfect solution, but it's surely better than nothing.  I'm aware of
Dan's arguments about syslog not being perfect, such as: you can spoof
it, because you can get denial of service problems, because it's not
(indefinitely) extensible.  While these may be all true, it sure beats
a boot to the head.  I just hate system programs that don't syslog.
And you don't want to hear what I have to say about systems without
syslog, and a modern one at that.  I simply don't use them.

As was mentioned earlier, *every* system call should *always*
be checked, even if you "know" it can't fail.  Look in the classic
paper referenced earlier.  One of its examples was from the init code;
something like:

    open("/", 0);
    dup2(0,1);
    dup2(0,2);

These can all fail.  I'd like the program to know it.  I'd also
like it if it found some way to tell me, but at least it shouldn't
ignore them just because it can't think of something better to do.

I know people say not to check for errors that you don't know how to
handle.  I think they're wrong. That's what asserts are all about.

I've spent more in the last 10 years tracking down program that don't
detect error conditions, or if they do, don't give me reasonable
messages, than I like to think about, all because some programmer
was too lazy or short-sighted to deal with the problem in an 
adequate and informative manner.

Yes, I've attempted to move the thread again.  I don't think it
belongs in BSD bugs anymore, although maybe Bostic et alii will 
notice the BSD reference above and amend any remaining deficiencies.
My check was many, many releases ago -- I don't how bad recent
Berkeley code is at this.

--tom
--
"Still waiting to read alt.fan.dan-bernstein using DBWM, Dan's own AI window 
manager, which argues with you for 10 weeks before resizing your window." 
### And now for the question of the month:  How do you spell relief?   Answer:
U=brnstnd@kramden.acf.nyu.edu; echo "/From: $U/h:j" >>~/News/KILL; expire -f $U