This is the mail archive of the
mailing list for the GCC project.
Re: "introduce no new bootstrap warning" criteria. was: Loop iv debugging, patch
- To: geoffk at redhat dot com, neil at daikokuya dot demon dot co dot uk
- Subject: Re: "introduce no new bootstrap warning" criteria. was: Loop iv debugging, patch
- From: "Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>
- Date: Sun, 14 Jan 2001 08:40:44 -0500 (EST)
- Cc: aj at suse dot de, dewar at gnat dot com, dkorn at pixelpower dot com, gcc at gcc dot gnu dot org, jsm28 at cam dot ac dot uk, robertlipe at usa dot net, zackw at Stanford dot EDU
> From: Neil Booth <firstname.lastname@example.org>
> Geoff Keating wrote:-
> > Or perhaps the macro expander should track which macros are defined in
> > system headers and not produce warnings for them?
> I'm not a fan of this option at all. The only warnings we can avoid
> this way are CPP warnings about the macro definition, which one
> would hope was valid anyway being in a system header.
> When it comes to usage, it gets really hairy because the invocation of
> the macro could have come from other macros or macro arguments,
> recursively who is to know whether those tokens come from user code or
> system headers? And to the front ends, tokens all look the same
> regardless of whence they came.
I'm not sure its as hairy as you suggest, Zack seemed to think it
could be done. See my previous posting on this topic which contains
references to his opinions from August.
> Zack showed Ulrich how to fix glibc to avoid the warning, and was
> rudely brushed off.
Well that aside, we still have problems with proprietary vendors whose
system header macros produce warnings when utilized in user code.
Geoff suggested fixincludes, but it would be a real pain to fix every
macro that could potentially cause problems. And some cases are a
catch-22, e.g. what about UINT_MAX which contains a U suffix? Using
UINT_MAX in user code causes -Wtraditional to complain about the U,
but without the U you get "decimal constant is so large it is
unsigned" problems. (Not that I would recommend getting rid of the U,
just that either way we're hosed.)
The only solution to this kind of problem IMHO is to teach gcc to
ignore warnings from macros defined in system headers. Zack outlined
a way to do this given an integrated preprocessor, is it still
workable given all the changes to the cpp infrastructure since August?
Kaveh R. Ghazi Engagement Manager / Project Services
email@example.com Qwest Internet Solutions