Re: Re: Where did the warning go?

["Eivind LM" <eivliste@online.no>]

On Wed, 25 Feb 2009 01:23:16 +0100, Tom St Denis  
<tstdenis@ellipticsemi.com> wrote:

> 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'

That is an example of a meaningless warning, and I would simply disable it  
if it was implemented. No big deal. If I felt like it, I would write an  
email to the gcc list and ask why anyone had implemented such a warning.

Anyway, I am sure GCC developers do their best to write warnings that  
point on actual potential problems. Likely problems as well as unlikely  
problems.

> 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?

It would probably take me 1 minute to disable the warning, then it would  
never bother me again.

> 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?

I'll repeat myslelf: If the compiler can guarantee that I don't loose  
precision in the assignment, then I don't want a warning.

In this case 'b' is a symbolic constant for the integer value 98, which  
can be perfectly represented as a char. So I don't want a warning.

However, if I have

   int a;
   ask_user(&a);
   char b = a;

then I think a warning is in place.

If splint gives a warning for the first case, then I would say that is a  
problem with splint. But I have never tried splint, and probably won't  
either since you so strongly discourage it :)

> 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.

As I wrote earlier, I consider these as two totally different things. In  
the first case, the value is changed. In the second case, the value is not  
changed.

The first case might have well defined behaviour. But anyway, my value is  
changed by 20%. If I wanted to skip the decimals from 2.5, then I would  
have casted the value to an int explicitly. That's why I want a warning in  
the cases where any of my values are implicitly changed.

This is my personal preference. I am not telling you which warnings you  
should use when you compile your own code, or which should be default in  
GCC.

I am just saying that 1) I would like to have a warning whenever an  
implicit conversion happens that might be "value destroying". And 2) since  
I consider this a serious issue, then I expect the other warnings in GCC  
(probably also those warnings that I am not aware of) to be serious as  
well. That's why I would like to enable the whole lot to find out what  
they can teach me.

>> 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.

So you are saying that the unlikely cases are less serious? Like the int  
to char assignment, that works fine because the int is *likely* to be in  
[0,255]? Then it turns out that the int can be 256 before assignment to  
char, in a very special corner case. How serious this is does not depend  
on how likely it is.

Generally, I would rather say less likely cases are more serious than high  
likely cases. The highly likely cases are usually easy to discover while  
testing the software anyway. The less likely cases are the ones that are  
hard to find when you test, and the most hard-to-debug problems you  
receive after release.

So I won't say nothanks if GCC have ability to warn me about the less  
likely cases.

> 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 have Bjarne's book for C++, and think it is a great reference. But I  
can't go about reading the whole thing and expect to be a fluent C++  
programmer the next day. There are several ways to learn. One good way for  
me is if possible problems in my own code are pointed out to me as early  
as possible. That way I can look up in the book to find what the problem  
is, and consider whether the problem is a real issue or not. Afterwards, I  
will actually remember what I read in the spec, since it was directly  
related to my own 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';

I think I understand your concern. But once again, I don't think a cast is  
mindless or useless if it actually changes the data value. The above cast  
does not change the data value, and I agree it should not be neccesary.

> 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.

I agree it takes more than just warning-free to be bug-free. But some of  
the hard-to-debug bugs can be avoided by warnings, so I want to use the  
warnings for all they are worht.

But we definitely have very different ideas about this, and probably won't  
get any closer to agree. But thanks for your opinions though, I learned a  
lot! :)

Eivind