On 10/2/06, Kaveh R. Ghazi <[EMAIL PROTECTED]> wrote:
> 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 certainly support this too.
> 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?
I was thinking STDC_0_IN_SYSTEM_HEADERS, but it can't hurt to audit
the fixincludes hacks too...
> 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__.
Oh, ugh, you're right.
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
Yeah, this should work. I *think* you can use #pragma GCC
system_header for this,
and I am not sure why the "- 0" bit is necessary?
zw
