Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
To: None <firstname.lastname@example.org, email@example.com,>
From: Christos Zoulas <firstname.lastname@example.org>
Date: 06/20/2005 20:31:29
On Jun 21, 12:06am, email@example.com (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...