This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Patch -Wtraditional, warn about `U' integer constant suffix
- To: zack at wolery dot cumb dot org
- Subject: Re: Patch -Wtraditional, warn about `U' integer constant suffix
- From: "Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>
- Date: Tue, 8 Aug 2000 10:59:10 -0400 (EDT)
- Cc: gavin at cygnus dot com, gcc-patches at gcc dot gnu dot org, rth at cygnus dot com
> From: Zack Weinberg <zack@wolery.cumb.org>
>
> __extension__ isn't appropriate and would require modifying the system
> headers.
I agree __extension__ isn't appropriate, but for a different reason.
It elides *pedantic* warnings not the regular kind. I was kicking
around the idea of adding a __nowarn__ keyword which would do the
analogous thing for regular warnings. Or __nowarn__ (<parameter>) so
one could elide specific types, e.g. __traditional__,
__sign_compare__, etc.
I disagree it would require modifying system headers. I.e. you
wouldn't stick __extension__ (or __nowarn__) into the limits.h
definition of UINT_MAX. Instead, you would add the keyword at the
point of usage in your own code, if it triggered a harmless warning.
> In theory, you could preserve information about where each macro
> definition came from. For all macros defined in system headers,
> toggle system-header-ness on and off when you step in and out of the
> expansion. This may be possible right now for warnings generated by
> the preprocessor. The compiler doesn't have access to that level of
> detail - the integrated preprocessor mode *could* do it, but you'd
> have to augment the interface. All in all, more work than I have time
> for right now.
> zw
How hard would it be just to do the standalone preprocessor part for
warnings generated by cpp? We could leave the integreated
preprocessor mode for later.
--Kaveh
--
Kaveh R. Ghazi Engagement Manager / Project Services
ghazi@caip.rutgers.edu Qwest Internet Solutions