Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!mimsy!umd5!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: Passing (char *) NULL to printf to match %s
Message-ID: <6174@brl-smoke.ARPA>
Date: Sat, 25-Jul-87 05:31:27 EDT
Article-I.D.: brl-smok.6174
Posted: Sat Jul 25 05:31:27 1987
Date-Received: Sat, 25-Jul-87 22:06:01 EDT
References: <166@qetzal.UUCP> <157@hobbes.UUCP> <875@bsu-cs.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) )
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 21

In article <875@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes:
>I believe that the interpretation of (char *) NULL when supplied as the
>actual parameter where printf is looking for a string may have changed
>over the years.  The "correct" behavior today, according to ANSI C as
>I know it, is for printf to print a token signifying that a NULL
>pointer was passed.  Microsoft C will print the string "(null)" when
>this happens.

The Draft Proposed Standard for C says no such thing.
(Unless it was approved in the June 1987 Paris meeting of X3J11;
it's not in the current draft as mailed to the committee members,
nor was it in the draft that went out for public comment.)

Some implementations of printf() do indeed catch the null pointer
and do something non-random with it.  My implementation does the
same thing as MicroSoft's.  But that is a matter of quality of
implementation; it is not required by the specs.  It is an ERROR
for a programmer to pass a null pointer to printf() except for
parameters corresponding to %p format specifiers.

FLAME:  I have yet to see anything posted by Dhesi that was correct.