From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jason Merrill To: seebs@monolith.solon.com (Peter Seebach), egcs@cygnus.com Subject: Re: linux libio status Date: Wed, 15 Oct 1997 16:51:00 -0000 Message-id: References: <19971015095211.03621@renaissance.loria.fr> <199710151419.JAA20162.cygnus.egcs@monolith.solon.com> X-SW-Source: 1997-10/msg00605.html >>>>> Peter Seebach writes: > In message < 19971015095211.03621@renaissance.loria.fr >, Olivier Galibert writes > : >> On Tue, Oct 14, 1997 at 11:23:49PM -0700, Joe Buck wrote: >>> We need to silence these warnings. For the NULL, I suggest a global >>> s/NULL/0/ in the C++ iostreams headers. There is no reason to write >>> NULL, it is just a source of problems like this (*especially* since >>> we have changed C++ to be strict about void*). >> Don't use '0' but '0L'. This way you will be OK with NULL in stdargs >> when int=32b and pointer=64b. > Assuming, of course, that 0L is 64 bits. Rumor has it that some > implementations chose to make int and long 32, pointer 64, and > (cough) "long long" 64. > Further, what of an implementation where long is *larger* than a > pointer, but int is the same size? Then you need 0, not 0L... This is why we have a NULL macro. The gcc stddef.h provides an appropriate definition, so we can put #undef NULL #define __need_NULL #include #undef __need_NULL somewhere strategic, and that should do the trick. > It would have been a little easier if C89 had ruled that NULL must > actually have pointer type, then you could just use it for anything > that would be taking arguments as (void *), and, if you're feeling > courageous and not-quite-perfectly-portable, you could just use it > for all the pointers... C89 may not have, but gcc defines it that way. Jason