> Yes, but IMHO libc should error-check stuff, even simple null pointer
> checks would save a lot of hassles.

There appear to be two schools of thought on these issues--they made
themselves known in the gets() debates...

View 1: libc should allow old code to compile and run without nuisances
	like printf()'s showing up when you run the program.  There is
	too much old code that people are trying to run on NetBSD and
	the people doing the "ports" don't necessarily understand the
	code or even (possibly) the C language and can't be expected
	to fix, say, trn on their own.

View 2: libc should "encourage" people to write good code by complaining
	whenever it notices incorrect or deprecated behavior/use.  Flagging
	errors as soon as possible makes the program more portable in the
	long run.

Now, it's not exactly the same issue--a core dump and program failure is
more annoying than a printf(), and (unlike in the gets() case) we can't
flag this one at link time.

Passing NULL to fclose() is wrong.  The behavior is undefined--which
means that it could cause, say, emacs to be exec()'ed, right?  ;-)

If fclose() accepts NULL and just returns, then some might say that it
was shirking it's duty by not pointing out a programmer error, but
others would say that it's just good defensive programming.

-allen

-- 
Allen Briggs - end killing - allen.briggs@bev.net ** MacBSD == NetBSD/mac68k **
   Where does all my time go?  <a href="http://www.netbsd.org/">Guess.</a>