Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!rutgers!ucla-cs!zen!ucbvax!decvax!decwrl!sun!gorodish!guy From: guy%gorodish@Sun.COM (Guy Harris) Newsgroups: comp.lang.c Subject: Re: Passing (char *) NULL to printf to match %s Message-ID: <24247@sun.uucp> Date: Mon, 27-Jul-87 15:15:33 EDT Article-I.D.: sun.24247 Posted: Mon Jul 27 15:15:33 1987 Date-Received: Tue, 28-Jul-87 07:31:45 EDT References: <166@qetzal.UUCP> <157@hobbes.UUCP> <875@bsu-cs.UUCP> Sender: news@sun.uucp Lines: 39 > 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. Well, you don't know ANSI C then. I quote from the October 1, 1986 draft: A.6.2 Undefined behavior The behavior in the following circumstances is undefined: ... + An invalid array reference, *null pointer reference*, or reference to an object declared with automatic storage duration in a terminated block occurs (\(sc 3.3.3.2). ("italics" mine.) As for "printf" (or, more correctly, "fprintf", since the description of "printf" and "sprintf" refer back to the description of "fprintf"), in its description of "fprintf" the ANSI C draft says nothing whatsoever about its behavior when a NULL pointer is passed as an argument to be converted with a "%s" conversion. > Microsoft C will print the string "(null)" when this happens. Many implementations do that, but that's just a common convention, not any sort of requirement. > I agree that passing NULL to printf is a bad idea, mostly because it's > not wise to assume that any C compiler conforms to ANSI specs, > especially since ANSI specs still aren't official. Unless the ANSI C spec changes before it becomes official, it will STILL be a bad idea to pass NULL to "printf". Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com