Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
To: None <port-xen-maintainer@netbsd.org, gnats-admin@netbsd.org,>
From: Bill Studenmund <wrstuden@netbsd.org>
List: netbsd-bugs
Date: 06/21/2005 00:52:02
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 17:51:52 -0700

 --jCrbxBqMcLqd4mOl
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 On Tue, Jun 21, 2005 at 09:04:49AM +0900, YAMAMOTO Takashi wrote:
 > > > i really think this kind of "suppress coredump" thing is a bad practi=
 ce.
 > > > if you want explicit checks, _DIAGASSERT is for you.
 > >=20
 > > I disagree. I think suppressing coredumpes is an excellent idea, where=
 =20
 > > reasonable.
 > >=20
 > > My day job is working on a shipping product. Core dumps are bad. Core=
 =20
 > > dumps generate customer service issues, and impact the reliaility of th=
 e=20
 > > product. I would much rather have customers reporting logs like "Error =
 X=20
 > > with client (null)" than passing back stack traces.
 >=20
 > yes, "(null)" can be useful or dangerous, depending on the calling contex=
 t.
 > however, there is no way for a library to know which is the case.
 > fixing your product is appropriate because you know it's useful there.
 
 But it's not broken.
 
 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=
 =20
 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=
 =20
 believe you should be explaining to us how this will make our programs=20
 better, rather than telling us to change our code.
 
 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 behavior=
 =20
 to puts(). And that's it. I believe this as I see printf("%s") being used=
 =20
 in error-case-logging code in programs, and I feel it is much simpler to=20
 let "%s" deal with NULL than to make EVERY caller be defensive.
 
 Take care,
 
 Bill
 
 --jCrbxBqMcLqd4mOl
 Content-Type: application/pgp-signature
 Content-Disposition: inline
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.2.3 (NetBSD)
 
 iD8DBQFCt2SoWz+3JHUci9cRAjDWAJ9lxKJL9ftfky7jztf6CdNd02rypACfc/b3
 AA7wXTypfd0rD+3hpbWqJp4=
 =SZs0
 -----END PGP SIGNATURE-----
 
 --jCrbxBqMcLqd4mOl--