From mboxrd@z Thu Jan  1 00:00:00 1970
From: Joe Buck <jbuck@synopsys.com>
To: Olivier.Galibert@mines.u-nancy.fr (Olivier Galibert)
Cc: jbuck@synopsys.com, egcs@cygnus.com
Subject: Re: linux libio status
Date: Wed, 15 Oct 1997 20:16:00 -0000
Message-id: <199710151843.LAA23738@atrus.synopsys.com>
References: <19971015194434.57156@renaissance.loria.fr>
X-SW-Source: 1997-10/msg00617.html

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