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

From: christos@zoulas.com (Christos Zoulas)
To: gnats-bugs@netbsd.org, port-xen-maintainer@netbsd.org,
	gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Cc: 
Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
Date: Mon, 20 Jun 2005 20:31:29 -0400

 On Jun 21, 12:06am, yamt@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote:
 -- Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
 
 |  > My day job is working on a shipping product. Core dumps are bad. Core 
 |  > dumps generate customer service issues, and impact the reliaility of the 
 |  > product. I would much rather have customers reporting logs like "Error X 
 |  > with client (null)" than passing back stack traces.
 |  
 |  yes, "(null)" can be useful or dangerous, depending on the calling context.
 |  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.
 
 I agree with Bill here. Having things core-dump for no reason is
 counter-productive. It is one thing to fix all the known instances
 of NULL arguments to %s (which one should try to do, but can never
 be sure that he caught them all), and another to make puts() and fputs()
 behave the same way as our printf/fprintf do in the presence of NULL
 pointers. The changes to puts/fputs is for consistency. Of course it
 would be nice if the (null) printing behavior was standardized, but
 this is not going to happen anytime soon...
 
 christos