This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: linux libio status
- To: Olivier dot Galibert at mines dot u-nancy dot fr (Olivier Galibert)
- Subject: Re: linux libio status
- From: Joe Buck <jbuck at synopsys dot com>
- Date: Wed, 15 Oct 97 11:43:02 PDT
- Cc: jbuck at synopsys dot com, egcs at cygnus dot com
> > Conclusion: we should deprecate the use of NULL in C++ code. If we
> > must define NULL for C++ code, it must be 0. Nothing else.
>
>
> You say "make sure that current code works but randomly crashes when the
> users upgrade to new 64bits architectures". I don't call that being
> fair to the user.
Stop putting words in my mouth. Since my C++ code has to run with
multiple compilers, I never use NULL and, on those rare occasions where
I must use a variadic function, I pass a null pointer of the right type.
What's unfair to the user is to tell the user he/she can use NULL in
any position where a pointer is required in C++ code. The problem is
that there is no definition that will work correctly and portably with
variadic functions. (But then, variadic functions are a bad idea, as
their arguments can't be type-checked at compile time except by special
means, like the gcc printf hack. Furthermore, they are rare except for
the printf family, and gcc has a special check for those).
> If your vision of "deprecating NULL" is "let users having their code working
> right now but crashing randomly when they eventually have the money to buy
> a 64bits processor" then yes, define NULL as 0.
So Stroustrup doesn't know what he's talking about? So every C++ author
in the book doesn't know either? For variadic functions that want a
pointer, 0L is just as broken as 0; on certain memory models for 16-bit
PC code, you will corrupt your stack (a near pointer, only 16 bits, is
expected and you push a four-byte quantity).
There's no substitute for programming correctly.