dhesi@bsu-cs.UUCP (Rahul Dhesi) (07/24/87)
In article <157@hobbes.UUCP> root@hobbes.UUCP (John Plocher) writes: >+---- (Robert White) writes the following in article <166@qetzal.UUCP> ---- >| 10. Passing (char *) NULL to a function in a large model program can cause >| a core dump/program abort. . . . >| This blows up a LOT of things, including printf("%s", (char *) NULL) >| (or equivalent). >+---- > > WRONG! Passing the NULL pointer is not what is wrong! What IS wrong > is the ASSUMPTION that the data stored at location NULL is anything useful! > > printf("%s", (char *) NULL); says print the string at address 0. This > happens to work on a VAX because that machine SPECIFICALLY has set things > up so that the contents of location 0 is 0. This bad coding practice > hits owners of Sun machines as well and is NOT a compiler bug. 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. However my System V Release 2 manual as supplied with Microport System V/AT says that printf's behavior on a NULL pointer is undefined. (Then again, the UNIX C compilers are quite far away from ANSI C, since they don't support function prototypes at all.) 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. I added comp.lang.c to the newsgroups heading, so the Real Gurus can give us their opinion. Let's keep followups there or, better still, let the Gurus have the last word. -- Rahul Dhesi UUCP: {ihnp4,seismo}!{iuvax,pur-ee}!bsu-cs!dhesi