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 plac
# 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.
That looks about right to me. KIASAP (as simple as possible,
no way is this coming out "simple". :) Cheers -Bruce
> 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 th
The runtime of what, gcc or fixincludes? Whatever solution we come up
with, I'd like to avoid duplicating setting STDC_0_IN_SYSTEM_HEADERS,
i.e. bad idea to do it once in gcc and once in fixincludes. Better is
if we can include the target config file somehow.
Let's not go down the road of incl
> > However I believe since fixincludes moved to the top level
> > directory we're no longer looking in the target headers and getting
> > that definition and thus the __STRICT_ANSI__ changes are always
> > applied, even when they're not supposed to be.
> > Am I reading the situation corr
Kaveh R. Ghazi wrote:
Thoughts on fixing it?
Blech! :-)
However I believe since fixincludes moved to the top level directory
we're no longer looking in the target headers and getting that
definition and thus the __STRICT_ANSI__ changes are always applied,
even when they're not supposed to be
Hmm... I just noticed that fixincludes is applying the
strict_ansi_not, strict_ansi_not_ctd and strict_ansi_only fixes on
solaris. Recall, these are the fixes that replace various checks on
__STDC__ with __STRICT_ANSI__. I'm pretty sure it's not supposed to
be applied on solaris. All of these fi
