#: From owner-current-users@NetBSD.ORG Thu Sep 14 11:59:31 1995
#: X-Authentication-Warning: frankenstein.piermont.com: Host localhost didn't use HELO protocol
#: To: callum@frost.bain.oz.au (Callum Gibson)
#: Cc: lukem@telstra.com.au, current-users@NetBSD.ORG
#: Subject: Re: Is fclose(NULL) defined? 
#: Reply-To: perry@piermont.com
#: X-Reposting-Policy: redistribute only with permission
#: Date: Tue, 12 Sep 1995 23:18:58 -0400
#: From: "Perry E. Metzger" <perry@piermont.com>
#: 
#: 
#: Callum Gibson writes:
#: > :-)Yes, but IMHO libc should error-check stuff, even simple null pointer
#: > :-)checks would save a lot of hassles.
#: > 
#: > If it's going to error-check stuff like that it should do it with asserts.
#: > To silently allow bad code like fclose(NULL) is simply encouraging bad
#: > programming.
#: 
#: Asserts are bad because they only are on if the program is
#: appropriately compiled. A simple "if (foo) abort();" is far better.

Or, in the case of fclose(), dereferencing the passed object is better still.
No special programming is needed, and the user program will blow up as soon
as the function in question hits the offending object (which, in the case
of fclose(), is right off).

Also, in situations like that, something which abort()s instead of letting a
SEGV go its natural course might prove a mite confusing.  I know that if
I do a trace and see something like

87:	fclose(fp);
(dbx) step
SIGIOT in fclose():  IOT trap
(dbx)

I'd probably wonder, "What the hell is so wrong with my C library that
it would generate an IOT?".

If I saw it report a SIGSEGV instead, my next question would probably be
(dbx) print fp
to which the response would likely be
fp = (nil)
(dbx)

Supposedly, anyone doing any programming will have taken the time to figure 
out the rudiments of what they're doing, at least enough to know that
they shouldn't call fclose() on something that fopen() failed to deliver,
and similar pitfalls.  libc() shouldn't lower its expectations to the
lowest common denominator (I *hate* systems that try to do this --
we end up lowering ourselves to the competency level of the most base
idiot, instead of trying to make the idiot aware, but that's another
(void *) (worm_t (*)())can;...).

I've been taken in by things like

	fprintf("This is going to dump core BIG time.\n", stderr);

just because I've been in a hurry and forgotten that I'm not using fputs()
instead.  It happens.

				--*greywolf;


#: 
#: .pm
#: