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.