Message-ID: <39741C0A.148E362F@softhome.net>
Date: Tue, 18 Jul 2000 10:57:46 +0200
From: Laurynas Biveinis <lauras AT softhome DOT net>
X-Mailer: Mozilla 4.73 [en] (Win98; U)
X-Accept-Language: lt,en
MIME-Version: 1.0
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
CC: djgpp-workers AT delorie DOT com
Subject: Re: GCC headers and DJGPP port
References: <Pine DOT SUN DOT 3 DOT 91 DOT 1000718111407 DOT 1391A-100000 AT is>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com

Eli Zaretskii wrote:
> > It seems that this time my mail has reached the target :-)
> 
> I hope so.  I'm still waiting to see any technical explanation; until now
> I didn't see any.

One response was technical, the one I've quoted in other reply.
(At least compare it with what we've read in GCC mail archives)

> Frankly, I don't see why do you think such changes will be accepted by
> the GCC maintainers: I didn't see any sign of commitment on their part.
> But I guess we could always try anyway...

I don't see any reasons (except for patch reviewal speed) why Mark's patch
shouldn't be accepted

+ #undef SIZE_TYPE
+ #define SIZE_TYPE "long unsigned int"

This patch ensures GCC & DJGPP will agree about types to some extent.

> sys/djtypes.h is there for a reason; I think ANSI doesn't allow stddef.h
> to be included by other headers.

Uhm, the notorious 'va_list in <stdio.h>' again. One possible hack from
glibc could be
#define __need_size_t
#include <stddef.h>

This way stddef.h from GCC will behave as it wasn't included at all - no
sentinels, no defs, no _STDDEF_H_INCLUDED, just single size_t definition.
Honestly I don't see any other way to do it.

Laurynas