Re: Re: Where did the warning go?

[Tom St Denis <tstdenis at ellipticsemi dot com>]

On Tue 24/02/09  7:09 PM , "Eivind LM" eivliste@online.no sent:
> I'm sure there are several opinions on what "annoying" and "useless"  
> warnings are. A warning can only annoy me if I don't do anything about it. 
> And "unlikely to be wrong" is not sufficient for me to consider the  
> warning to be useless.
> 

Yeah, the problem is you can have warnings for things that don't need warnings. 
Like for example:

int a;
a = 4;

warning:  the variable name "a" is too short, and doesn't contain the letter 'e'

Is a "valid" warning, since a conforming compiler may produce ANY warning it want
(the spec only specifies what warrants a diagnostic (error)).  Now if GCC emitted
that warning would you find that useful?  Or perhaps would it get in the way of
real work?

Now onto something less trivial ...

char a = 'b';

You're assigning an "int" type to a char.  splint will warn you about this, even
though it's perfectly reasonable and well understood [not to mention portable]
code.  Is that useful?

In your own example passing 2.5 to a function declared with an int parameter. 
That has well defined behaviour as well.  It's no less defined than say passing
"5" to a function that accepts a long.

> I take all warnings as an opportunity to learn some specific details about 
> the language. I am a novice, and trust the GCC developers have a good  
> reason to write each warning. It is usually easy to get the idea of the  
> possible problem when a warning triggers in my own code. Then I either  
> find out that the problem can absolutely never ever affect me (and then I  
> would disable the warning), or I change my code. I have never been sure  
> enough yet to disable any of the warnings I have seen so far.

The goal of good warnings is to detect things that are likely to be bugs, or are
at least undefined behaviour.  Not to warn about things that have clearly defined
behaviours.  If you want to learn more about C, pick up the ISO C draft and read
it.  Don't rely on the warnings from GCC to teach you what is and isn't good C code.
 
> I do of course think differently if I work with old code that has too many 
> warnings to fix. But encouraging everyone to compile their new code with  
> as many warning flags as possible could eventually solve that problem? :)

It is indeed a good goal to have warning free code, but adding mindless and
useless casts everywhere (for instance) is just as annoying coding practice.  I
wouldn't accept code that read, like

char a = (char)'b';

As it's superfluous and will make reading the code harder, not easier.

It's why a lot of people avoid tools like splint (if their corporate masters
don't dictate it's use) because 99 out of 100 times the warnings produced don't
lead to anything that could even remotely possibly be a bug.  It's irresponsible
to trace down and "fix" what isn't broken.  Specially when there are better tools
out there like valgrind to help debug your apps.

> Anyway, we don't have to agree on this. I just wish to have a flag that  
> let me compile my own code with as many warnings as possible. And then the 
> name of the -Wall flag is in the way.

I'm trying to help you by persuading you that that's not a good idea.  Learn the
C standard and code within it's boundaries.  Don't rely on superfluous warnings
to avoid bugs because at the end of the day it's not a sufficient condition for
bug free code to be splint warning free.

Tom