Message-ID: <39742B45.D30B4051@softhome.net> Date: Tue, 18 Jul 2000 12:02:45 +0200 From: Laurynas Biveinis X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: lt,en MIME-Version: 1.0 To: Eli Zaretskii CC: djgpp-workers AT delorie DOT com Subject: Re: GCC headers and DJGPP port References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: djgpp-workers AT delorie DOT com Eli Zaretskii wrote: > > + #undef SIZE_TYPE > > + #define SIZE_TYPE "long unsigned int" > > I'm not sure I understand what exactly is this suggestion. Where should > this snippet go, and how would it solve the problem(s) at hand? It would go to GCC source, target description header file. The explanation was earlier in this thread: > In message <200007172102 DOT XAA07817 AT loewis DOT home DOT cs DOT tu-berlin DOT de>you write: > > 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. > The "how" of this question is the port maintainer figures out the right > value and codes it into the target .h file. For example: > > /* Make GCC agree with types.h. */ > #undef SIZE_TYPE > #undef PTRDIFF_TYPE > > #define SIZE_TYPE "long unsigned int" > #define PTRDIFF_TYPE "long int" > Actually, I don't think I understand why stddef.h needs to be included > instead of djtypes.h. Could you please explain? Let's say we've converted to GCC headers. Now some header wants to get size_t. Earlier he was including . But now the only header which knows about size_t is , but including it is prohibited. Thus there is a backdoor - you define __need_size_t, __need_null, etc. and include . Then it will silently give out only requested definitions and nothing else. Laurynas