named warnings & individual warning control

[Dale Johannesen]

On Jun 25, 2004, at 4:21 PM, Mark Mitchell wrote:
> Stan Shebs wrote:
>> Mark Mitchell wrote:
>>
>>> [...] I have long argued that only front ends should be permitted to 
>>> issue warnings, and that all attempts to use back-end data flow 
>>> analysis to issue warnings are mistaken, no matter how clever they 
>>> seem.

I agree warnings that appear only at certain optimization levels are 
evil.
I'm not so sure that duplicating a lot of BE functionality in the FE is 
a good
idea.   It seems to me what you want is a way to run the existing data 
flow in
a lightweight mode, so that it doesn't change the code at all, just 
detects
uninitialized variables.

>  inline bool f() { return true; }
>
>  void g() {
>     int i;
>     bool b = f();
>
>     if (b) i = 3;
>     h(i);
>  }
> Here, GCC with -O2 will probably not warn about the use of "i", since 
> the assignment always takes place.  (The compiler will do inlining, 
> constant propagation, remove the branch, etc.)
>
> Arguably, GCC's behavior is not what people want anyhow; a change to 
> the implementation of "f" will cause the code above to become unsafe.

I haven't heard a user make that argument, and it doesn't seem like a 
very good one.   If "f" is changed to make the above unsafe,
and the code is recompiled, you would get a warning at that time.

On the contrary, we do get a lot of complaints about false positives.  
Steve Johnson once wrote:

> Lint was a difficult program to write...partially because users 
> usually don’t notice bugs which cause lint to miss errors which it 
> should have caught. (By contrast, if lint incorrectly complains about 
> something that is correct, the programmer reports that immediately!)

and users don't seem to have changed much.