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>
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

- Raw text -