This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: linux libio status
- To: seebs at monolith dot solon dot com (Peter Seebach), egcs at cygnus dot com
- Subject: Re: linux libio status
- From: Jason Merrill <jason at cygnus dot com>
- Date: 15 Oct 1997 11:57:19 -0700
- References: <19971015095211.03621@renaissance.loria.fr><199710151419.JAA20162.cygnus.egcs@monolith.solon.com>
>>>>> Peter Seebach <seebs@monolith.solon.com> 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 <stddef.h>
#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