Path: utzoo!utgpu!cunews!cognos!jimp From: jimp@cognos.UUCP (Jim Patterson) Newsgroups: comp.std.c Subject: Re: gcc and NULL function pointers. Message-ID: <9752@cognos.UUCP> Date: 20 Jun 91 20:41:51 GMT References: <1991Jun19.182420.12673@athena.mit.edu> Reply-To: jimp@cognos.UUCP (Jim Patterson) Organization: Cognos Inc., Ottawa, Canada Lines: 37 In article peter@ficc.ferranti.com (Peter da Silva) writes: > >The "best" definition for "NULL" is entirely compiler/hardware dependent. I don't agree. Any compiler should generate the SAME code whether you define NULL to be 0 or (void*)0, provided it is coerced to the correct pointer type where used. So, (void*)0 should always be correct if you follow the rules, regardless of compiler/hardware, and generate equivalent code. On the other hand, defining NULL to be 0 allows NULL to be misused as a non-pointer constant. For example, I've seen this code around here the odd time: char x[5]; x[4] = NULL; /* sic */ If NULL is (void*)0, these slipups will likely be caught. If only some compilers define it this way, you only find out about it when you compile with those compilers. >And that's the point of *having* a standard for the language, after all. Which is why there should be a standard definition. It avoids suprises when porting to new environments. Except for the substantial prior art for #define NULL (0), I think (void*)0 is ALWAYS the best definition. Of course, prior art is an important consideration, so I can't fault the X3J11 group for leaving the definition somewhat ill-defined, but if it were designed again from scratch I think the argument for #define NULL (0) would be pretty weak. -- Jim Patterson Cognos Incorporated UUNET:uunet!cognos.uucp!jimp P.O. BOX 9707 BITNET:ccs.carleton.ca!cognos.uucp!jimp 3755 Riverside Drive PHONE:(613)738-1440 x6112 Ottawa, Ont K1G 3Z4