<<marginal to current users>>

>> 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.

Good summary - you simply can't reconcile an immediate pragmatic
perspective (view 1) with a longer-term one based on the right thing (view
2). What's best depends on the person and circumstances.

Instead of rerunning religious wars maybe both can be catered for, thereby
leaving the argument to which should be the default out-of-the-box
behaviour of NetBSD. Checks could be included in library routines for NULL
pointers and some other simple nasties. Make them conditionally compiled
and/or enabled by a __NetBSD_do_library_sanity_checks=0 in main(), and
maybe even sysctl'able if you want to go to extremes.

Maybe now that the brain-deadness of {v}sprintf() has finally bitten people
in the syslog brouha, those routines could print a warning a la gets(). I
think not because: the problem with gets() has been known from early days
and fgets() is available as the routine which should be used. {v}sprintf()
may not be as widely used, but there was simply no alternative until(?)
4.4's {v}snprintf(). Interestingly, the wide character versions introduced
in Ammendment 1 to ISO C include a buffer size parameter. Unfortunately it
seems the opportunity to add a {v}snprintf() facility was not taken up.

cheers,
Danny Thomas  (D.Thomas@vthrc.uq.edu.au)