An interesting behaviour in printf

[Wayne A. Throop]

> gwyn at smoke.BRL.MIL (Doug Gwyn )
>> throopw at dg-rtp.dg.com (Wayne A. Throop)
>> I'd druther do something close to
>>     kill( getpid(), SIGSEGV );
>> [..when a printf %s format is passed a null pointer..]
> 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.

Ah.  Good point: when a program is being developed, unexpected output
in one form is as good as that in another.  Adequate testing will
discover these kinds of thing.  But what I had in mind was that such
an implementation of the printf family shouldn't make it into
production code.  People tend to scan things superficially, and may
well miss such a thing as (null) in a column of entries of some sort
(especially if something like N/A or whatnot is a valid entry).  If
the users don't happen to note it, they won't ask to have it fixed.
Hence, I'd druther have a somewhat more attention-getting occurance
for this error.  Not that I claim Doug is "wrong"... these are largely
taste issues after all.  I just point out that his experience leading
to his decision to print (null) seems pointed towards the development
environment instead of the use environment.  But "I could be wrong,
you know!"

(Note that with adequate debugging support, there is nothing to
prevent continuing to the next error after raising the first...
raising it as an error rather than as an unexpected output just
"shouts louder" so to speak.)

--
If someone tells me I'm not really conscious, I don't marvel about
how clever he is to have figured that out... I say he's crazy.
          --- Searle (paraphrased) from an episode of PBS's "The Mind"
--
Wayne Throop      <the-known-world>!mcnc!rti!xyzzy!throopw