Re: linux libio status

[Olivier Galibert <Olivier dot Galibert at mines dot u-nancy dot fr>]

On Wed, Oct 15, 1997 at 11:43:02AM -0700, Joe Buck wrote:
> There's no substitute for programming correctly.

I think I wasn't clear enough.

I completely agree with 95% of what you said. The only point
I disagree with is "we must #define NULL 0 because Stroustrup
said so".

Without adding special support for a __null keyword or whatever,
we have only two reasonable possibilities for NULL which are 0
and 0L.

The choice between them is without a real impact except in the
case of passing NULL in a varadic function call with the old
C meaning (void *)0. Telling "Thou shan't use NULL in such calls"
is irrelevant. I know better than using them, but we're in the
real world and anyway it was perfectly valid one or two
years ago when implicitely converting from (void *) wasn't yet
ruled out. Which means we have a lot of code floating around
which requires passing such a NULL to work. Just for the record
xemacs was in this case some months ago.

Now, what should we do ? We can't without additional support warn
for such code. Besides, would we be able to warn that we could be
_sure_ to do the Right Thing in all cases, i.e. implicitely use
a (void *)0. I don't think gcc supports multisized pointers anyway.
We can't even make a choice which will lend to crashes in most of
the current platforms since they are 32/32/32 (int/long/pointer)
and the distinction between int and long doesn't exist in our case.

Given this situation I really think that the only fair approach is
the ensure that for most of the people the code will keep working
in the future.

Now, the new architectures are 32/32/64, 32/64/32 and 32/64/64.
32/32/64 is hosed, both choices will lend to crashes.
32/64/32 will almost always work with NULL=0, and will work on
         a lot of architectures with NULL=0L.
32/64/64 (which are the irix 6 and dec alpha cases, I know no
         real-world implementations of the previous two) will
         almost always work with NULL=0L and never work with
         NULL=0.

The "almost always" comes from the fact that some calling conventions
separate "data" and "pointers" and so no integer type will do for
a pointer.

This means we have the choice between using 0 and crashing badly
on current 64bits architectures but working on some weird ones,
or using 0L and working on these real architectures while keeping
a fair chance to work on the weird ones.

Conclusion: we're here to help people make programs, not implementing
            language non-normative politics.

  OG.