This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: cpplib: Start moving switch handling to front ends


Neil Booth <neil@daikokuya.co.uk> writes:
> 
> Stan Shebs wrote:-
> 
> > If we're willing to touch the warnings in GCC, we could add an
> > official name to each one that we want to control, so for instance
> > you would say
> > 
> >  warning ("comparison-always-true",
> >    "comparison is always true due to limited range of data type");
> > 
> > and that would automatically create -Wcomparison-always-true and
> > add to a warning control pragma.  Although the names do add to the
> > code, warnings-conscious users need well-defined terminology to talk
> > with each other about which warnings they're interested in.  Explicit
> > names also allow us to use the same name if the exigencies of coding
> > require the use to multiple warning() calls for a single kind of
> > warning.
> 
> Hmm, OK, interesting.  But how is this better than just numbering
> each warning?

For myself, I like names better than numbers in warnings.

Part of the problem is the 'official' number space for GCC derivatives.
It may occur that one or more organizations (*BSD, Apple, Redhat, et al)
may have versions of GCC that contain local patches, including new
warnings that are not immediately merged into the gcc.gnu.org sources.
This skew is nasty for users of 'gcc' when the number space manages to
allocate more than one numeric warning to different constructs in the
code base. While names may also have this problem, they are less likely
to be in conflict than numbers.

I will also note that if there is to be a revision on how warnings work,
it might also be nice to adapt -Werror to allow levels of severity in
order to transition to new versions of the compiler. If you have just
the old '-Werror', then any warning the compiler generates should error
out. However, it might be nice to find some way let 'new' warnings that
have been added to the compiler since the previous release to be less
fatal to the compilation, but still let the user know that the warning
needs to be fixed eventually... Or maybe we need a syntax to make
particular 'warnings' really be 'errors' like

   '-Werror=comparison-always-true,unused'
or '-Werror-comparison-always-true -Werror-unused' 
or '-Wcomparison-always-true -Wunused -Werror'

In other words, the -Werror switch implicitly add an 'error' property to
each -Wflag rather than having all warnings be errors.

Similarly, there should be a way to make a warning just a warning rather
than an error

   -Werror -Wunsigned -Wcomparison-always-true -Wno-error=uninitialized

would generate an error for 'unsigned' and 'comparison-always-true' but
just a plain warning for 'uninitialized' ...

	-- Mark


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]