Wish: Variable Not Used Warning

[Sean Kelly]

Walter Bright wrote:
> Nick Sabalausky wrote:
>> "Walter Bright" <newshound1 at digitalmars.com> wrote in message 
>> news:g530j8$18th$1 at digitalmars.com...
>>> The reason for treating warnings as errors when warnings are enabled 
>>> is so that, for a long build, they don't scroll up and off your 
>>> screen and go unnoticed.
>>
>> Pardon me for saying so, but that doesn't sound like a very convincing 
>> reason to turn every warning (which, by it's very nature, is something 
>> that might not be a bug) into something that splits the language into 
>> what are effectively different languages.
> 
> I'll draw on my 25 years of experience with warnings to answer this.
> 
> If you turn warnings on, then you want to see them and presumably deal 
> with them. If you don't deal with them, then they persist every time you 
> compile, and either they get very irritating and you fix them anyway, or 
> you develop a blind spot for them and never see the ones you do want to 
> fix.

This is true.  However, warnings are often related to code structure and 
the compiler isn't perfect at identifying real problems... and code 
changes to work around deficiencies in the checking tool aren't always 
appealing.  For example, there is a file in the GC code, if I remember 
correctly, that doesn't compile correctly with warnings enabled because 
it uses a goto or some such that confuses the compiler about what's 
going on.  If this were C++ I might be inclined to pragma out that 
particular warning for the area where the warning is displayed.

Another issue is with third-party libraries.  I always compile my code 
with the strictest warning settings, yet some of the libraries I use 
aren't so careful.  With them, the easiest thing to do it often to 
assume that they work correctly despite the warnings and disable warning 
messages for the relevant headers.

> Piping the output into a file and then perusing it manually looking for 
> warning statements is never going to happen. Complex builds tend to 
> produce a lot of output, and poking through it looking for warnings 
> every time you build is not practical. Changing your build process to 
> point out warnings is the same thing as the compiler treating them as 
> errors, except it's extra work for the build master.

It isn't practical to do so for every build, but it's not uncommon for a 
team to set aside some time to address warnings in bulk, say between 
releases.

> Trying to educate your programmers into doing extra work to deal with 
> warnings that scroll off the screen is a lost cause.
> 
> If you're using a static analysis tool, such as Coverity, which produces 
> lots of spurious warnings, it is not put in the build process. It's run 
> occasionally as a separate evaluation tool.

That's certainly an option, and probably a preferable one overall.


Sean