> Let's not go down the road of including the target config file in
> more places which are not part of the compiler proper - which are
> not even inside the gcc directory!
I agree, but I also want to avoid duplicating the info in two places,
it makes maintenance harder.
> I'd like to see this used as an occasion to determine whether we
> still need this particular hack, which I have never been fond of.
Which hack? The STDC_0_IN_SYSTEM_HEADERS hack, or the strict_ansi_*
fixincludes hacks? Or both? I'm pretty sure solaris10 no longer
needs either one, but older releases of solaris do. I can't speak for
other svr4 targets or interix. My concern is that we should be
consistent, since applying the fixincludes hacks depends on not having
stdc_0_in_system_headers.
> If we really still do, the Right Thing would be to add another
> undocumented built-in preprocessor macro,
> __STDC_0_IN_SYSTEM_HEADERS__ say, which is defined only if
> CPP_OPTION(pfile, stdc_0_in_system_headers) is true.
> zw
I don't see how this will work given that fixincludes is built with
the bootstrap compiler in 4.0 and 4.1 which has no notion of your new
macro __STDC_0_IN_SYSTEM_HEADERS__.
For 4.2 and later, while fixincludes is three-staged, we'll still have
problems in stage1 fixincludes or with --disable-bootstrap
configurations using your scheme.
Another option might be to use the resulting gcc compiler just built
and compile an autoconf style check to see whether system headers
define __STDC__ to 1. We can create a testcase that fakes being in a
system header by using those digits in the line number directives
right? I forget the format, but I seem to recall one of the trailing
digits signifies we're in a system header. Then just see if you can
compile this:
# fake us into system header land...
#if __STDC__ - 0 == 0
#error "STDC_0_IN_SYSTEM_HEADERS"
#endif
If it fails, then fixincludes knows we have stdc_0_in_system_headers.
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
