Re: linux libio status

[Olivier Galibert <Olivier.Galibert@mines.u-nancy.fr>]

On Wed, Oct 15, 1997 at 09:04:20AM -0700, Joe Buck wrote:
> > Don't use '0' but '0L'. This way you will be OK with NULL in stdargs
                                                                 ^^^^^^^
> > when int=32b and pointer=64b.

I was explicitely talking about functions with '...' in them.


> The only exception is functions with ... in their spec.  Here, neither 0
> nor 0L will result in portable code.  Your suggestion switches the
> erroneous assumption that sizeof(T *) == sizeof(int) with another
> erroneous assumption, that sizeof(T *) == sizeof(long).  Worse, you leave
> users with the idea that they can safely use NULL for any null pointer
> type, even in variadic functions.  Sorry, you can't do that in standard
> C++.  For variadic functions, users must declare any optional arguments
> correctly, period.
> 
> 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. The current existing architectures I know about are:
- 32bits int, 32bits long, 64bits long long, 32bits ptr
- 32bits int, 64bits long, 64bits long long, 64bits ptr

The first one concerns almost all unixes. The second is relevant in Irix 6
and on alphas. Other probably exist but are an order of magnitude less
present. Besides, the probability is high that most of the code works
if sizeof(T *)<=sizeof(NULL). This depends on parameter-passing conventions.
Code can't work with sizeof(T *)>sizeof(NULL).

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. If you want to be as nice as
possible to the user while not changing the compiler, define it as 0L. If you
really want to deprecate it define it at __null, make it behave the right way
w.r.t type conversions and warn when used as parameter in a varadic function
or in constructions like "int a=NULL;".

  OG.