Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!rutgers!ames!sdcsvax!ucbvax!decvax!minow
From: minow@decvax.UUCP (Martin Minow)
Newsgroups: comp.lang.c
Subject: Re: Passing (char *) NULL to printf to match %s
Message-ID: <122@decvax.UUCP>
Date: Wed, 29-Jul-87 19:26:53 EDT
Article-I.D.: decvax.122
Posted: Wed Jul 29 19:26:53 1987
Date-Received: Sat, 1-Aug-87 00:49:51 EDT
References: <166@qetzal.UUCP> <157@hobbes.UUCP> <875@bsu-cs.UUCP> <3533@ihlpg.ATT.COM>
Reply-To: minow@decvax.UUCP (Martin Minow)
Organization: Digital Eq. Corp. - Merrimack NH.
Lines: 26

In article <3533@ihlpg.ATT.COM> ejbjr@ihlpg.ATT.COM (Branagan) writes:
>Some time ago I noticed one of our VAXes printing a NULL pointer as
>"(null)".  I thought it was neat that printf now detected NULL string
>pointers and did something sensible, until I found out that this only
>worked because the loader stored the string "(null)" at location 0.
>This apparently broke so many other programs it was backed out, and
>location 0 now has a 0 in it again.   Oh well...
>-- 

Sorry, those programs were broke to begin with.  Some history:
Unix V6 stored a zero at memory location zero.  Thus, printf("%s", 0)
printed "" and, as always happens, people came to rely on this.
Decus C printf (which I wrote) detected a NULL argument and changed
it to "{null}" rather than print garbage or crash.  (PDP11's running Dec
operating systems loaded non-zero values at location zero.)  I assume
other developers implemented similar tests for similar reasons.

VMS doesn't map virtual locations 0 through 511 to trap these dereferencing
errors, so these bugs got shaken out of programs as they were ported to
Vax C.

You are asking for trouble if your programs expect to survive memory
accesses to random locations.

Martin Minow
decvax!minow