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 16:32:55 -0700

 --kfjH4zxOES6UT95V
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 On Tue, Jun 21, 2005 at 07:17:11AM +0900, YAMAMOTO Takashi wrote:
 > > I agree with this -- it sounds like any justification for printing
 > > "(null)" is based on the fact that it is actually used, and there
 > > is no good reason for fputs() to not have the same checking, other than
 > > that puts() is rarely called with NULL.
 >=20
 > i really think this kind of "suppress coredump" thing is a bad practice.
 > if you want explicit checks, _DIAGASSERT is for you.
 
 I disagree. I think suppressing coredumpes is an excellent idea, where=20
 reasonable.
 
 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 the=20
 product. I would much rather have customers reporting logs like "Error X=20
 with client (null)" than passing back stack traces.
 
 I agree that main-path coding shouldn't depend on this, and that it should=
 =20
 be detecting NULL (and other invalid values) on its own. The place though=
 =20
 that I find the "(null)" behavior VERY useful, though, is in diagnostic=20
 log messages in case of an error. If I get a string I don't understand, I=
 =20
 can log "I didn't understand %s\n", return an error code, and move on.=20
 Without a core dump.
 
 If, however, we reverted this, I'd have to put a chunk of defensive code=20
 in all of my error case handling. That would mean lots of duplicated=20
 value checking code. And the value checking has, in the code where I=20
 implemented it, made the code harder to follow and maintain. I'd rather=20
 not make the error case handling code distract from the main flow of the=20
 routine.
 
 Take care,
 
 Bill
 
 --kfjH4zxOES6UT95V
 Content-Type: application/pgp-signature
 Content-Disposition: inline
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.2.3 (NetBSD)
 
 iD8DBQFCt1InWz+3JHUci9cRAtB1AJ4gLklErKU0vQcTPvLWpFljAgFrwgCeMeTI
 ucxc0m7h/gT5Wbnw4ZgVzAA=
 =SGgZ
 -----END PGP SIGNATURE-----
 
 --kfjH4zxOES6UT95V--