Mail Archives: djgpp-workers/2000/06/04/11:01:15
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.
- Raw text -