Date: Thu, 26 Mar 1998 10:49:44 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: DJ Delorie <dj AT delorie DOT com>
cc: salvador AT inti DOT gov DOT ar, blizzar AT hem1 DOT passagen DOT se, djgpp-workers AT delorie DOT com
Subject: Re: NULL redefined! :(
In-Reply-To: <199803252349.SAA09833@delorie.com>
Message-ID: <Pine.SUN.3.91.980326104922.29215D-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk


On Wed, 25 Mar 1998, DJ Delorie wrote:

> The C version of the macro works for C++ also, so why add complexity
> where it isn't needed?

As I understand it, without doing something about that, perfectly
correct programs trigger errors and fail to compile.  Isn't this
reason enough to do *something*?

> DJGPP shouldn't have to change to adapt to third-party libraries
> when DJGPP is in compliance with the published specifications.

Let me be sure I understand what you are saying.  Are you saying that
libstdc++ is the ``third-party library'' which should be changed, and
that we should complain to its developers and request that they stop
breaking DJGPP?

I don't oppose to this approach, but I somehow doubt that it will
prevail.  I'd bet libstdc++ developers considered these cases also,
and if they did that anyway, it was probably for a good reason
(rooted, no doubt, in C++ obscurities).

OTOH, having a different definition is a relatively minor compromise
on our side, IMHO.

> Comparison of different pointer types?  Once NULL has a type, there
> are *less* things you can compare it against, not more.
> 
> Some other things:
> 
> 1. WHY DO WE NEED THIS?  The "0" definition is perfectly fine, and has
>    worked for what, twenty years or so?
> 
> 2. "NULL = foo;" would suddenly start working.
> 
> 3. ANSI C explicitly states that NULL must be one of the following: 0,
>    0L, or (void *)0.

These are all valid reasons.  However, if NULL is __null only in C++
programs, and then only in those which use libstdc++, then ANSI C is
not affected at all.  In fact, even ANSI C++ is not affected in
programs which avoid using libstdc++ (you can write C++ programs
without that library, after all).  We probably can arrange for NULL to
be different from the usual 0 *only* when libstdc++ is used (so
"#ifndef __cplusplus" is not right, we need a symbol which is specific
to libstdc++).

I suspect that using libstdc++ (at least in its current version) is
not even possible with a definition of NULL, which is different from
__null.  Changing that, if at all possible, will probably take time.
It's not right (IMHO) to tell people not to use libstdc++ in the
meantime.