Re: "introduce no new bootstrap warning" criteria. was: Loop iv debugging, patch

[Neil Booth <neil at daikokuya dot demon dot co dot uk>]

Kaveh R. Ghazi wrote:-

> 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.

You could set in_system_header when using a system macro, but that's a
bit of a sledgehammer approach.

For macros in general, it is not easy to know where they start or
finish e.g. macros arguments can cross the boundary of one macro and
another and / or the source file.  Also, the number of macros (even in
GCC itself) that take arguments which are or contain the name of
another macro to invoke is huge.  Look at some of the hairy testcases
- one from Jamie Lokier makes my mind boggle.

These things really do make the general situation more complex. You
could also be turning off warnings that are useful, e.g. all the
printf format checking warnings would go, since that was defined in a
system header, right?

The particular example of the warning that started this thread, about
ISO macros and a missing argument, *is* easily fixable if we track
where macros were defined (since it refers merely to the form of the
invocation of that macro).

But I remain _very_ sceptical that any of this is a good idea.  Also
GCC has enough overhead as it is - I don't want to add more without
good reason.

> 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.)

I think people using -Wtraditional would have to accept the U suffix
warning - it is what they asked for, after all.  That warning is IMO
less important than the signedness one.  I don't think current
behaviour is particularly broken.

> 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?

As I said, you could take the approach that once a system header macro
is used, you suppress warnings.  But I think this would end up being
really confusing, and causing a lot of stuff to be suppressed.  The
front ends currently keep track of systemheader-ness themselves, they
would need to be updated to use CPP exclusively for this information
(which by itself is a good idea anyway, IMO).

Neil.