Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
To: None <email@example.com>
From: YAMAMOTO Takashi <firstname.lastname@example.org>
Date: 06/21/2005 10:28:00
> While you are correct that the library has no way of knowing which of the
> two choices it should use, our common practice for printf() has been to
> not core dump. We have had that behavior since 4.4BSD, i.e. longer than
> there has been a NetBSD. Thus BSD developers decided that not core dumping
> was the better choice overall.
> You are the one who is championing making printf() and puts() and friends
> core dump when passed NULL. That's changing behavior for printf(). Thus I
> believe you should be explaining to us how this will make our programs
> better, rather than telling us to change our code.
i think you are missing the context. my reply was about puts.
i didn't propose to change the historical behaviour of printf.
it's way too late to change. :(
> I agree we should not make system libraries, by default, perform a lot of
> extra input validation. I believe that _DIAGASSERT is fine for them.
> However I believe that printf() for the '%s' format and puts() are
> different. I believe we should retain the printf "(null)" behavior and,
> especially in light of the gcc optimization, we should extend the behavior
> to puts(). And that's it. I believe this as I see printf("%s") being used
> in error-case-logging code in programs, and I feel it is much simpler to
> let "%s" deal with NULL than to make EVERY caller be defensive.
if you follow gcc (ie. honor compiler's right to do
this kind of optimization), you can't use non-standard extensions anyway.
if you don't follow gcc (ie. disable the optimization),
you don't need to extend the extension to puts.
in either way, i don't see any good reason to propagate
the extention to puts.