Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
To: None <port-xen-maintainer@netbsd.org, gnats-admin@netbsd.org,>
From: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
List: netbsd-bugs
Date: 06/21/2005 01:29:02
The following reply was made to PR port-xen/29887; it has been noted by GNATS.

From: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
To: wrstuden@netbsd.org
Cc: jhawk@MIT.EDU, christos@zoulas.com, gnats-bugs@NetBSD.org,
	port-xen-maintainer@NetBSD.org, netbsd-bugs@NetBSD.org,
	tech-userlevel@NetBSD.org
Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
Date: Tue, 21 Jun 2005 10:28:00 +0900

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