The following reply was made to PR port-xen/29887; it has been noted by GNATS.

From: Bill Studenmund <wrstuden@netbsd.org>
To: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
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: Mon, 20 Jun 2005 21:11:42 -0700

 --WlEyl6ow+jlIgNUh
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 On Tue, Jun 21, 2005 at 10:28:00AM +0900, YAMAMOTO Takashi wrote:
 > > While you are correct that the library has no way of knowing which of t=
 he
 > > 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 dump=
 ing=20
 > > was the better choice overall.
 > >=20
 > > You are the one who is championing making printf() and puts() and frien=
 ds
 > > core dump when passed NULL. That's changing behavior for printf(). Thus=
  I=20
 > > believe you should be explaining to us how this will make our programs=
 =20
 > > better, rather than telling us to change our code.
 >=20
 > 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. :(
 
 Ahhh... Ok.
 
 The problem though is that thanks to gcc, how puts() behaves is how=20
 printf() behaves some of the time. So printf() no longer has its=20
 historical behavior.
 
 > > I agree we should not make system libraries, by default, perform a lot =
 of=20
 > > extra input validation. I believe that _DIAGASSERT is fine for them.=20
 > > However I believe that printf() for the '%s' format and puts() are=20
 > > different. I believe we should retain the printf "(null)" behavior and,=
 =20
 > > especially in light of the gcc optimization, we should extend the behav=
 ior=20
 > > to puts(). And that's it. I believe this as I see printf("%s") being us=
 ed=20
 > > in error-case-logging code in programs, and I feel it is much simpler t=
 o=20
 > > let "%s" deal with NULL than to make EVERY caller be defensive.
 >=20
 > if you follow gcc (ie. honor compiler's right to do
 > this kind of optimization), you can't use non-standard extensions anyway.
 >=20
 > if you don't follow gcc (ie. disable the optimization),
 > you don't need to extend the extension to puts.
 >=20
 > in either way, i don't see any good reason to propagate
 > the extention to puts.
 
 You've defined everything in a very black & white manner, and in such a=20
 way that both scenarios support your opinion. That's not really a good=20
 starting point for an exchange of ideas.
 
 Exactly what puts() does is up to us in the areas of "standards undefined"=
 =20
 behavior, is it not? So we are free to add "(null)" support as I=20
 understand it. I really don't see why we shouldn't. What do you think will=
 =20
 be broken or what will we lose?
 
 The reality is we will probably have to live with gcc making assumptions=20
 for us. And to be honest, if we change puts(), then the assumption gcc=20
 makes (that printf("%s\n", x) yields the same effect as puts(x) for all x)=
 =20
 is once again true.
 
 Take care,
 
 Bill
 
 --WlEyl6ow+jlIgNUh
 Content-Type: application/pgp-signature
 Content-Disposition: inline
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.2.3 (NetBSD)
 
 iD8DBQFCt5N+Wz+3JHUci9cRAkYOAJ9BaCkN9J5FQzwg3xHh+VcoMGnTsACeIky0
 3YX2vx8F5/FUSKg0SazsvYc=
 =f9Wc
 -----END PGP SIGNATURE-----
 
 --WlEyl6ow+jlIgNUh--