patches pending review November-January

[Dirk Mueller]

On Thursday, 1. February 2007 18:10, Manuel López-Ibáñez wrote:

> > Hmm, I don't like the inflation of -W*comparison* if we don't even have
> > a -Wcomparison. At the least, -Wcomparison-fixed is inconsistent
> > with -Wstring-literal-comparison (a very ugly name imho).
> -Wcomparison? What is that warning about? I (as an user) would prefer
> descriptive names. If that cannot be done in one word, then it is
> better to use two words.

IMHO a warning name should be short and memorizeable. To understand what a 
warning is about, the actual warning text should be descriptive or 
alternatively the documentation about the warning clarifies the reason.

The issue with long warning names is that you can not remember them easy. Is 
it -Wstring-literal-comparison, -Wliteral-string-comparison 
or -Wcomparison-string-literal or even -Wcomparison-literal-string? Not to 
speak about non-native speakers who have troubles spelling comparison or 
literal. 

> but -Wcomparison-fixed is bad. A bit 
> arbitrary, isn't it?

I think the arbitrariness comes from the fact that we're not consistent 
regarding -WXXX-comparison and -Wcomparison-XXXX. 

IMHO some consitency should be there. For example we could introduce 
a -Wcomparison that only enables warnings that are really really rarely false 
positive. The annoying data range warning should be put under a suboption. 
How to name that suboption is open to discussion, but one idea would be: 

-Wextra-comparison

The other idea would be (in order to have fine grained control): 

-Wcomparison-literals
-Wcomparison-fixed
-Wcomparison-mathematical 

The idea is that -Wcomparison will only enable those suboptions that are 
considered to be "good" (no/low false positives). Those who want the control 
can use -W(no-)comparison-XXX. 

-Wextra-comparison could unconditionally enable all -Wcomparison-XXX 
suboptions. -Wextra will (compatibility!) enable all -Wextra-* options. 

The same issue is with -Wconversion. Some of those warnings are really useful, 
but the bulk of them are just annoying. If I compile real world code with it, 
I'm totally swamped by the false positives. 

> There are many reasons why these warnings should not go into
> -Walways-true. I already explained this elsewhere:

I've not said that it should be part of -Wall. Read carefully. 

> (Another option could be to remove the warning altogether. That would
> be nice indeed.)

I would not oppose to that, I've not seen any usefulness coming from this 
warning other when porting it to a new platform. 




Dirk