Date: Mon, 17 Jul 2000 23:02:50 +0200 Message-Id: <200007172102.XAA07817@loewis.home.cs.tu-berlin.de> From: "Martin v. Loewis" 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") Content-Type: text/plain; charset=US-ASCII 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 > 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