Date: Sun, 4 Jun 2000 18:00:40 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: Laurynas Biveinis cc: "Mark E." , DJGPP Workers Subject: Re: Testers wanted: a fix for GCC header problem In-Reply-To: <393959CC.186D9B30@softhome.net> Message-ID: MIME-Version: 1.0 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 On Sat, 3 Jun 2000, Laurynas Biveinis wrote: > 1) limits.h - it uses #include_next. Fine with us, not very fine with GCC maintainers. > It is somehow wrong for embedded systems, as they say. That was the reason, why > #include_next wasn't adopted to other header files. I'm afraid I don't understand their reasoning. Does someone know more about this? Any pointers to discussions on public forums? Also, #include_next redefines the constants that are already defined (by whatever precedes it in the header GCC installs), no? If so, the compiler could print warning messages under some restrictive -Wfoo option. > 2) float.h - problem with it are in the past now. How do you mean: in the past? Does GCC install its own float.h? If so, how can we be sure that it won't conflict with the DJGPP library? > So right now I see adding __dj_include_foo_h_ to GCC headers as a Must Have. The key to this is to understand why does GCC insist on installing its own headers. Using them when GCC is built is one thing, but installing it is quite another! Can someone please explain why does GCC want to install its headers? > In the case GCC maintainers do not accept that, one of the remaining > solutions (not counting overriding USER_H, omiting offending files etc.) > is to change our file-level sentinels from __dj_include_foo_h_ to > _ANSI_FOO_H. How can we be sure these sentinels won't change? I think we cannot.