Date:	Thu, 20 Jul 2000 14:05:06 +0200
Message-Id:	<200007201205.OAA15361@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:	<200007201024.GAA09536@indy.delorie.com> (message from Eli
	Zaretskii on Thu, 20 Jul 2000 06:24:10 -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> <200007200729 DOT JAA01060 AT loewis DOT home DOT cs DOT tu-berlin DOT de> <200007201024 DOT GAA09536 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")
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

> > I had hoped you could have concluded that it either does or
> > does not break the library.
> 
> We couldn't do that because we had no information on how __null works
> in the C++ compiler.  If we missed something in the docs, please tell
> where we should have read about it.

It is not in the texinfo documentation, as it is not intended to be
used by anybody then the "implementation" itself (which consists of
the compiler, and the standard library). There is a note in cp/NEWS
you may not have seen, though.

However, I thought you are *maintainers* of the compiler
(specifically, the DOS port of it). So if you had a long discussion,
why didn't you ask on gcc AT gcc DOT gnu DOT org, or look at the source code to
see what __null does, or consult the ChangeLogs to find out who
installed that change, and contacted the author?

> I explained the technical reasons in a message I sent today.  If it
> didn't yet reach you, soon it will.  If I still failed to explain
> something, please tell what needs further explanation.

I've looked through all your messages so far, and I could only find
one problem: redefinition of NULL. Although this would be certainly a
bug, I'm not all that clear how that could ever happen. You wrote

>> The problem is with C++ programs that include <stdio.h> or <cstdio>
>> (or stddef.h etc.)  after C++ headers such as <libio.h>: these
>> define NULL, and GCC then complains about its redifinition.

I don't know what your copy of stdio.h looks like, however, it should
certainly test whether NULL is defined before defining it. So in this
case, I'd say there is a bug in <stdio.h>.

It may be that there is also a bug in the program: No program should
include <libio.h>; instead, it should always include <stdio.h>, or
<iostream>.

If there were further problems, please tell me as I may have missed
them in all these messages.

> What is of interest to us is what will a C function see when called
> with a __null argument from a C++ program.  

What do you mean by "will see"? At run-time, the value on the stack
will be a 0x00000000 bit pattern for the parameter, at least on 32-bit
machines.

Regards,
Martin

- Raw text -