Date: Thu, 20 Jul 2000 09:29:35 +0200
Message-Id: <200007200729.JAA01060@loewis.home.cs.tu-berlin.de>
From: "Martin v. Loewis" <martin AT loewis DOT home DOT cs DOT tu-berlin DOT de>
To: eliz AT is DOT elta DOT co DOT il
CC: lauras AT softhome DOT net, mrs AT windriver DOT com, gcc AT gcc DOT gnu DOT org,
        djgpp-workers AT delorie DOT com
In-reply-to: <200007191826.OAA08693@indy.delorie.com> (message from Eli
	Zaretskii on Wed, 19 Jul 2000 14:26:25 -0400 (EDT))
Subject: Re: GCC headers and DJGPP port
References: <200007180918 DOT FAA06988 AT indy DOT delorie DOT com> <200007181913 DOT VAA01170 AT loewis DOT home DOT cs DOT tu-berlin DOT de> <200007191826 DOT OAA08693 AT indy DOT delorie DOT com>
User-Agent: SEMI/1.13.3 (Komaiko) FLIM/1.12.5 (Hirahata) Emacs/20.4 (i586-pc-linux-gnu) MULE/4.0 (HANANOEN)
MIME-Version: 1.0 (generated by SEMI 1.13.3 - "Komaiko")
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> > > Anyway, one reason that __null might cause trouble is that it breaks
> > > previous versions of the library which were compiled with different
> > > definition of NULL.  I think we've been discussing that on the DJGPP
> > > developers list to death.
[...]
> Seriously, though: the conclusion was that we didn't like the
> redefinition of NULL in C++ headers (see my other message for the
> problems this causes).

So you had all this discussion to agree on a mental state (you don't
like it)? I had hoped you could have concluded that it either does or
does not break the library. If it does break the library, exactly why?
If it does not break the library, what is the problem?

Please try to be technical instead of political - especially if you
are asking the same from GCC developers!

> But we couldn't understand why does the C++ compiler redefines NULL
> in its headers, so we couldn't find a solution that would satisfy us
> all and avoid breaking the C++ compiler at the same time.  Perhaps
> you could help.

It's very easy. In C++, NULL is an "implementation­defined C++ null
pointer constant", according to 18.1, [lib.support.types]/4. That
means, "possible definitions include 0 and 0L, but not (void*)0".

If you define NULL as 0, you find that

#include <stdlib.h>
void foo(int);
void foo(int*);

int main()
{

  foo(NULL);
}

will compile flawlessly and invoke the first function, even though it
is probably the author probably meant to express a pointer. The reason
is that passing 0 into an int is an exact match, whereas converting it
to int* is a conversion. Please note that the exact meaning of this
program could depend on the platform - if the parameter is a typedef
that is "long int" on some systems and "int" on others, the meaning of
this program changes.

The same problem exists with

  throw NULL;

which does not do what the user would expect (i.e. it throws an int,
or long - not a null pointer). There are a few more common program
mistakes involving a misunderstanding of NULL. Those can only be
detected if the compiler *knows* that this used to be NULL, hence the
__null keyword.

I believe this feature of g++ has proven useful, and I'd certainly
expect that all ports of g++ support it.

Regards,
Martin