Subject: Re: port-xen/29887: sysctl kern.consdev coredumps
To: YAMAMOTO Takashi <>
From: Bill Studenmund <>
List: netbsd-bugs
Date: 06/20/2005 16:32:55
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.
> 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

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=
be detecting NULL (and other invalid values) on its own. The place though=
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=
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

Take care,


Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.2.3 (NetBSD)