--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--