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