Message-Id:	<200006061748.UAA20575@alpha.netvision.net.il>
Date:	Tue, 06 Jun 2000 20:47:47 +0200
X-Mailer:	Emacs 20.6 (via feedmail 8.1.emacs20_6 I) and Blat ver 1.8.5b
From:	"Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
To:	Laurynas Biveinis <lauras AT softhome DOT net>
CC:	djgpp-workers AT delorie DOT com
In-reply-to:	<393BE1CA.B06CAC0F@softhome.net> (message from Laurynas Biveinis
	on Mon, 05 Jun 2000 20:22:18 +0300)
Subject:	Re: Testers wanted: a fix for GCC header problem
References:	<3939239A DOT 18870 DOT 336AAF AT localhost> <393BE1CA DOT B06CAC0F AT softhome DOT net>
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

> Date: Mon, 05 Jun 2000 20:22:18 +0300
> From: Laurynas Biveinis <lauras AT softhome DOT net>
>
> In file included from ../../gcc/tsystem.h:52,
>                  from ../../gcc/libgcc2.c:37:
> d:/djgpp/include/stdio.h:35: warning: redefinition of `va_list'
> include/stdarg.h:112: warning: `va_list' previously declared here
> d:/djgpp/include/stdio.h:38: warning: redefinition of `size_t'
> include/stddef.h:200: warning: `size_t' previously declared here
> In file included from ../../gcc/tsystem.h:69,
>                  from ../../gcc/libgcc2.c:37:
> d:/djgpp/include/stdlib.h:39: warning: redefinition of `wchar_t'
> include/stddef.h:288: warning: `wchar_t' previously declared here

Yep, known problems.  If you search the mail archives, you will find
these popping up time and again, since the GCC maintainers took their
attitude.

> I'm afraid to make the conclusion that DJGPP headers should reuse GCC
> sentinel system. This would be an internal change, so FAQs should
> remain minimized. I could take responsibility for making this change
> and ensure the absence of problems.

I would really like to explore the other solution first: namely, to
get the GCC maintainers to refrain from forcing their headers on
compliant libraries.  It is simply _not right_ for a compiler to force
a library to track changes in compiler's configury.  A reasonably
complaint library should be able to proceed with its development
without having to consult the latest GCC CVS tree.

It strikes me that the maintainers should re-read what Richard
Stallman wrote in the thread about strict-aliasing nuisance: that
gratuitously breaking code of compiler's users is not just harsh
policy, it's a policy of being harsh!  And that a maintainer should
adopt a policy of being kind to users, not being harsh.

- Raw text -