Path: utzoo!utgpu!watmath!rbutterworth
From: rbutterworth@watmath.waterloo.edu (Ray Butterworth)
Newsgroups: comp.lang.c
Subject: Re: An interesting behaviour in printf
Message-ID: <24450@watmath.waterloo.edu>
Date: 22 Mar 89 15:28:32 GMT
References: <960@Portia.Stanford.EDU> <15938@cup.portal.com> <2343@buengc.BU.EDU> <9891@smoke.BRL.MIL>
Organization: U of Waterloo, Ontario
Lines: 20

In article <9891@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn ) writes:
> In article <4273@xyzzy.UUCP> throopw@agarn.dg.com (Wayne A. Throop) writes:
> >I'd druther do something close to
> >    kill( getpid(), SIGSEGV );
> >in such a case.
> 
> All I can say is, my experience with this has been that printing "(null)"
> has not encouraged non-portable coding here (but then I try to stamp it
> out anyway), and letting the application continue to run has usually been
> more helpful than harmful.  Normally upon seeing "(null)" in output where
> some meaningful string was expected, the software maintainer fixes the
> null pointer bug and no damage was done.

Unfortunately many people will rely on this feature and believe it
is actually part of the C language and library.  (Consider all the
postings to this group over the years that claim this fact.)

A better idea than "<null)" would be a somewhat more obnoxious string
such as: "a null character pointer was erroneously passed to printf".
It would achieve the effect that you want and the one that Wayne wants.