Date:	Mon, 17 Jul 2000 23:02:50 +0200
Message-Id:	<200007172102.XAA07817@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:	mrs AT windriver DOT com, gcc AT gcc DOT gnu DOT org, djgpp-workers AT delorie DOT com
In-reply-to:	<200007171834.OAA06211@indy.delorie.com> (message from Eli
	Zaretskii on Mon, 17 Jul 2000 14:34:27 -0400 (EDT))
Subject:	Re: GCC headers and DJGPP port
References:	<200007171736 DOT KAA29313 AT kankakee DOT wrs DOT com> <200007171834 DOT OAA06211 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

> How about a system with its own stddef.h?  Standard types such as
> size_t, wchar_t, the definition of NULL -- these are surely closely
> related to the internals of a library, right?  And GCC has no means
> of knowing how to define these correctly for the library, right?

Wrong. GCC needs to know exactly what size_t and wchar_t is, and it
must also provide the definition of NULL. size_t must be known so the
builtin functions can be declared properly. wchar_t must be known so
wide string literals can be emitted correctly. NULL is defined as
__null on all platforms now, so that overloading works correctly in
C++ (for C, it is something different).

Now, the exact mechanism *how* it is achieved that the header file is
an exact match of the target understanding of these types is a tricky
question, however, there is no question *that* gcc must know about
these types even without seeing a single target header file.

Regards,
Martin

- Raw text -