This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: linux libio status



> > 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]