Re: Re: Where did the warning go?

Re: Re: Where did the warning go?

[Tom St Denis]

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

Re: Re: Where did the warning go?

[Eivind LM]

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

Re: Where did the warning go?

[Tom St Denis]

Eivind LM wrote:
>> 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.
Don't mix types then?  I know of no reason to use "char" unless you're 
dealing with strings or octet data.  I'd never use a char in a 
day-to-day expression (e.g. as an index to an array, counter, etc).

> However, if I have
>
>   int a;
>   ask_user(&a);
>   char b = a;
>
> then I think a warning is in place.

Why?  It's defined behaviour.  Your real problem is mixing types, not 
the promotion problems.

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

But it has defined behaviour. 

> 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.
Don't mix types?  If you're writing a DSP or other math library chances 
are you wouldn't have random functions that take int and some that take 
float. 

> 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.
Ok, but -Wconversion exists.  Don't go tacking that onto -Wall so us 
programmers who know what we're doing get stuck with it.

> 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.
No, it's less serious because it's defined behaviour. 

> 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.
I have yet to really have any defects found by trivial and 
hypersensitive syntax checking.  Wait till you have a 60,000 line 
project with hundreds of inter dependencies between functions, then 
you'll start worrying about something a little more serious than defined 
behaviour.
> So I won't say nothanks if GCC have ability to warn me about the less 
> likely cases.
I have to ask you, what percentage of bugs do you suppose are attributed 
to storing int's in chars (or similar)?  10%?  1%?  0.001%? 

And how much will you miss because you spend time worrying about things 
like this instead of just developing properly to start with?

Just like micro-optimizations can be time consuming and wasteful, so can 
micro-linting.

>> 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.
Yeah, but again, you want warnings for things that aren't errors or 
undefined behaviour.  Where do you draw the line?

If you want to learn how to develop software, just pick problems and 
solve them with software.  Then test and verify, document and support.  
GCC won't teach you how to be a good developer.  And frankly, there is a 
heck of a lot more to being a software developer than knowledge of the 
syntax of a given language.

> 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.
But it's your type of thinking that leads to those warnings in the first 
place.  Then customers get wind of that and *demand* that we address 
them.  It's really annoying.

> 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.
Ok, but while you're wasting time chasing down every useless warning, 
you're *not* learning about proper defensive coding, you're *not* 
learning about common defects, and you're *not* becoming a good software 
developer.

If you really want to learn how to debug/fix software, get familiar with 
gdb, valgrind, and the like.  Learn about common defects like buffer 
overflow/runs, race conditions, etc.

> 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! :)
Just wait till you have customers with "coding standards" like MISRA or 
whatever that say things like "goto can never be used."  Right after you 
put together a package which uses them exclusively (for error 
handling).  Pointless coding rules (of which I lump in useless warnings) 
lead people to miss the bigger picture, and in the end real defects that 
plague large software projects. 

You don't see it now, maybe because you haven't been on the working end 
of a large project, but trust me.  You won't gain experience until you 
actually work on projects, and those projects will have defects, and 
your defects will likely not be syntax related.

Tom

Re: Where did the warning go?

[Eivind LM]

On Wed, 25 Feb 2009 15:20:34 +0100, Tom St Denis  
<tstdenis@ellipticsemi.com> wrote:

> Eivind LM wrote:
>>> 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.
> Don't mix types then?  I know of no reason to use "char" unless you're  
> dealing with strings or octet data.  I'd never use a char in a  
> day-to-day expression (e.g. as an index to an array, counter, etc).
>
>> However, if I have
>>
>>   int a;
>>   ask_user(&a);
>>   char b = a;
>>
>> then I think a warning is in place.
>
> Why?  It's defined behaviour.  Your real problem is mixing types, not  
> the promotion problems.

So you think it is a problem to mix types? Then we agree on something. The  
code example was a response to your paragraph above where you wrote that  
"assigning int type to char is perfectly reasonable and well understood".  
I would not write such code. If I mistakenly assign an int to a char, then  
I would like a warning, no matter how well defined the behaviour is.

>> 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.
>
> But it has defined behaviour.
>> 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.
> Don't mix types?  If you're writing a DSP or other math library chances  
> are you wouldn't have random functions that take int and some that take  
> float.

Exactly: don't mix types. Don't send a double as parameter to a function  
that takes int (which you wrote is well defined behaviour). Don't compare  
a float to an int (which you earlier wrote is perfectly valid).

If I do something like that by mistake, then I would like the compiler to  
warn me, no matter if it's valid or well defined, because the code might  
not do what I intended.

>> 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.
> Ok, but -Wconversion exists.  Don't go tacking that onto -Wall so us  
> programmers who know what we're doing get stuck with it.

Yes, I found -Wconversion to be very useful. I wonder how many other flags  
there are in GCC that might prove to be just as useful for me. If there  
was a -Weverything flag, then it would be easy to find out.

I will not go about tacking any warnings on anyone. The only thing I'm  
saying about -Wall is that the name is confusing and should be changed.

>> 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.
> No, it's less serious because it's defined behaviour.

We are talking about behavour which is possibly unintended, right? That's  
when I would like a warning. I don't understand why you think the  
consequence (or seriousness) of the unintended behaviour is related to its  
likelihood to fail, or whether the behaviour is well defined or not.

>> 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.
> I have yet to really have any defects found by trivial and  
> hypersensitive syntax checking.  Wait till you have a 60,000 line  
> project with hundreds of inter dependencies between functions, then  
> you'll start worrying about something a little more serious than defined  
> behaviour.

Ok. I have about 50,000 lines of C++ code so far. The lines are spread  
over different libraries though, so it's not the same project.

>> So I won't say nothanks if GCC have ability to warn me about the less  
>> likely cases.
> I have to ask you, what percentage of bugs do you suppose are attributed  
> to storing int's in chars (or similar)?  10%?  1%?  0.001%? And how much  
> will you miss because you spend time worrying about things like this  
> instead of just developing properly to start with?

Less likely does not mean less serious.

I am a human, and make mistakes from time to time. I expect to keep making  
mistakes, even after the next 50 years of experience with C++. But I don't  
want to make a mistake in 50 years from now, that a GCC warning today  
could have tought me to avoid.

> Just like micro-optimizations can be time consuming and wasteful, so can  
> micro-linting.
>
>>> 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.
> Yeah, but again, you want warnings for things that aren't errors or  
> undefined behaviour.  Where do you draw the line?
>
> If you want to learn how to develop software, just pick problems and  
> solve them with software.  Then test and verify, document and support.   
> GCC won't teach you how to be a good developer.  And frankly, there is a  
> heck of a lot more to being a software developer than knowledge of the  
> syntax of a given language.

But that does not make the syntax part less important for me.

>> 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.
> But it's your type of thinking that leads to those warnings in the first  
> place.  Then customers get wind of that and *demand* that we address  
> them.  It's really annoying.

By "those warnings", you mean a warning for something that is absolutely  
sure to not be a problem under any circumstance?

Could you please write and send me some example code that cause a  
non-trivial warning with gcc, and where you can prove that there is no  
potential problems with the code? I have yet to see such a warning, and it  
would be very educating for me to see.

>> 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.
> Ok, but while you're wasting time chasing down every useless warning,  
> you're *not* learning about proper defensive coding, you're *not*  
> learning about common defects, and you're *not* becoming a good software  
> developer.
>
> If you really want to learn how to debug/fix software, get familiar with  
> gdb, valgrind, and the like.  Learn about common defects like buffer  
> overflow/runs, race conditions, etc.

I use gdb and valgrind. I have done my time debugging writes outside array  
boundaries. I have used pthreads and debugged race conditions. But I still  
care about compiler warnings. I don't think there is a contradiction there.

>> 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! :)
> Just wait till you have customers with "coding standards" like MISRA or  
> whatever that say things like "goto can never be used."  Right after you  
> put together a package which uses them exclusively (for error  
> handling).  Pointless coding rules (of which I lump in useless warnings)  
> lead people to miss the bigger picture, and in the end real defects that  
> plague large software projects. You don't see it now, maybe because you  
> haven't been on the working end of a large project, but trust me.  You  
> won't gain experience until you actually work on projects, and those  
> projects will have defects, and your defects will likely not be syntax  
> related.

You keep using the word "likely". If there is only a slightest chance that  
one of the warnings can save me one of the really hard debugging sessions,  
then I will keep caring about compiler warnings.

Eivind

Re: Where did the warning go?

[Tom St Denis]

Eivind LM wrote:
> So you think it is a problem to mix types? Then we agree on something. 
> The code example was a response to your paragraph above where you 
> wrote that "assigning int type to char is perfectly reasonable and 
> well understood". I would not write such code. If I mistakenly assign 
> an int to a char, then I would like a warning, no matter how well 
> defined the behaviour is.
I think it's more important to not make the mistake in the first place.  
If you're writing code where you freely interchange data types all 
willy-nilly, you have bigger problems than what warnings GCC emits.  
It's like saying you need spell check in your email client to write well.

> Exactly: don't mix types. Don't send a double as parameter to a 
> function that takes int (which you wrote is well defined behaviour). 
> Don't compare a float to an int (which you earlier wrote is perfectly 
> valid).
But I would expect known behaviour.  For example, if I were writing a 
FIR or IIR function and happened to have int data, I wouldn't expect a 
warning from passing an int to a function that accepts float.  If I 
passed an "int *" to a function that takes "float *" I would expect a 
warning because the code is clearly wrong and won't work properly.
> If I do something like that by mistake, then I would like the compiler 
> to warn me, no matter if it's valid or well defined, because the code 
> might not do what I intended.
But you shouldn't be in a position where you're freely interchanging 
data types in random expressions anyways.  If you are, you need to 
re-write your algorithm from scratch.


> I will not go about tacking any warnings on anyone. The only thing I'm 
> saying about -Wall is that the name is confusing and should be changed.
Except for everyone else who lives with it and is getting on just fine.  
I'm ok with an additional flag, I just don't want -Wall to change (in 
this respect anyways).

>>> 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.
>> No, it's less serious because it's defined behaviour.
>
> We are talking about behavour which is possibly unintended, right? 
> That's when I would like a warning. I don't understand why you think 
> the consequence (or seriousness) of the unintended behaviour is 
> related to its likelihood to fail, or whether the behaviour is well 
> defined or not.
Because not everyone accidentally mixes types.  If I store a long in an 
unsigned char, that I know is in range [or I don't care about the higher 
order bits] I don't want my compiler bitching and whining to me over 
something that has clearly defined behaviour.

Let me put it this way, you can write perfectly syntactically correct 
code that has the complete opposite meaning of what you want, for 
example "if (a = 3) { ... }".  I'm for catching that one because it's a 
typo in 99% of cases and is good to find. 

Where as storing a long in a char is *not* a typo, it's a design flaw, 
and it means you don't know what you're doing if you're worried about 
losing precision.

> Ok. I have about 50,000 lines of C++ code so far. The lines are spread 
> over different libraries though, so it's not the same project.
And you think loss of precision is your biggest problem?  ... Ok.

> Less likely does not mean less serious.
It's an irresponsible use of time to hunt down and fix things that 
aren't actually bugs when you can very likely have real bugs in your 
software.

> I am a human, and make mistakes from time to time. I expect to keep 
> making mistakes, even after the next 50 years of experience with C++. 
> But I don't want to make a mistake in 50 years from now, that a GCC 
> warning today could have tought me to avoid.
And what I'm trying to tell you is your not better served by having 
pedantic warnings about things that aren't undefined behaviour or 
obvious typos.


>> Just like micro-optimizations can be time consuming and wasteful, so 
>> can micro-linting.
I like how you didn't reply to this.


> But that does not make the syntax part less important for me.
The syntax should be second nature to you.  I resort to looking at the 
draft or the ANSI C spec maybe once a year and even then it's over very 
obscure things that you don't see on the day to day development tasks.  
You should know your order of precedences and associativity off the top 
of your head, you should know the type promotions of expressions and 
what not right away.

> By "those warnings", you mean a warning for something that is 
> absolutely sure to not be a problem under any circumstance?
Not everyone is so unsure about the syntax and language as you are.
> Could you please write and send me some example code that cause a 
> non-trivial warning with gcc, and where you can prove that there is no 
> potential problems with the code? I have yet to see such a warning, 
> and it would be very educating for me to see.
Well the warning you desired that started this thread is a good 
example.  The sort of things splint warns about are good examples, etc, 
and so on.

> You keep using the word "likely". If there is only a slightest chance 
> that one of the warnings can save me one of the really hard debugging 
> sessions, then I will keep caring about compiler warnings.
And you will miss a whole slew of real problems because you're worried 
about micro-linting your code. 

More warnings is only a good idea if the warnings are in fact useful and 
likely to represent real life bugs.  Warning about the type promotion of 
expressions is just annoying and frankly, a complete waste of time.  Put 
it this way, for every warning you want to see, try and imagine what 
percentage of bugs in the real world are attributed to it. 

Now you're gonna say "but if there is a chance ..."  .... but then I'll 
say the time you waste on it is time not spent shoring up your code, 
then'll you say "but if there is a chance ..." and I'm just going to 
give up now.

Tom

Re: Where did the warning go?

[John Z. Bohach]

On Wednesday 25 February 2009 08:16:23 am Tom St Denis wrote:
> Eivind LM wrote:
<...snip...>

I've been reading this thread, and there is an important point that 
hasn't been made yet, or at least I would like to emphasize it if it 
has:

Compiler default behavior changes are _REALLY_ annoying.  Even when its 
done to fix a gcc bug, or for other good reasons, it still causes a lot 
of churn either in fixing Makefiles or fixing source code.

I build custom distributions as well as various other s/w for a living, 
and just upgrading my toolchain from 4.0.2 to 4.2.2 caused almost half 
(of the over 200) purely open-source packages that I build to either 
need a patch or upgrade to a new version...and this is especially true 
with C++ code.

Those clamoring for default behavior changes should consider that many 
(millions, probably) of source packages would likely need modifications 
if/when basic default behaviors change.  And -Wall changes are as basic 
as it gets.

I think it is a legitimate gripe that the warnings with -Wall are not 
set in stone already, and sometime change even now, but the solution is 
certainly not to change it some more.

However, I recognize that people may want a -Weverything flag, and that 
does seem like a reasonable compromise, as that could be used as a 
poor-man's splint or other static-analysis tool.  I happen to agree 
with Tom that lint and such is not a substitute for good programming 
practices, but what the heck...if the gcc developers can be convinced 
to add a -Weverything, why not.  AS LONG AS THE CURRENT DEFAULTS STOP 
CHANGING.

Re: Where did the warning go?

[Ian Lance Taylor]

"John (Eljay) Love-Jensen" <eljay@adobe.com> writes:

> As long as I'm making wishes, I also wish warnings were emitted like this:
> test.cpp:6: -Wunused warning: unused variable 'u'
> ...rather than...
> test.cpp:6: warning: unused variable 'u'

As of gcc 4.2, you can get something like this if you use
-fdiagnostics-show-option.

Ian

Re: Where did the warning go?

[Andrew Haley]

John (Eljay) Love-Jensen wrote:
> Hi everyone,
> 
> [Tom]> I think most long term developers really just want the warnings for
> two things.  Things that are undefined behaviour, and things that are likely
> a typo...
> 
> I don¹t mind keeping -Wall with the current meaning, and not deprecating it.
> 
> I, as a long term developer who has been developing for over 30 years, and
> in C/C++ for over 20 years, using GCC since 2.95 came out, do wish that
> there was a -Weverything flag that enabled all -W* toggle warnings.
> 
> Why?
> 
> Because I use GCC as a lint-like tool.
> 
> I like to be able to see what warnings my code generates, vet those warnings
> and vet my code, then decide to disable the warning or fix my code.

Hmm.  I don't know that some warnings may not be contradictory: damned if
you do, damned if you don't.  I wonder.

Andrew.

Re: Where did the warning go?

[Tom St Denis]

John (Eljay) Love-Jensen wrote:
> Hi everyone,
>
> [Tom]> I think most long term developers really just want the warnings for
> two things.  Things that are undefined behaviour, and things that are likely
> a typo...
>
> I don¹t mind keeping -Wall with the current meaning, and not deprecating it.
>
> I, as a long term developer who has been developing for over 30 years, and
> in C/C++ for over 20 years, using GCC since 2.95 came out, do wish that
> there was a -Weverything flag that enabled all -W* toggle warnings.
>   
I'm actually ok with *adding* a new macro flag [e.g. -Weverything].  I 
just don't want the defaults to change so radically.

> Why?
>
> Because I use GCC as a lint-like tool.
>
> I like to be able to see what warnings my code generates, vet those warnings
> and vet my code, then decide to disable the warning or fix my code.
>   
Which sounds reasonable to me.  I don't dismiss things like splint 
because I'm lazy or dislike standards.   My position stems from 
experience with the tools and to this day never finding a bug in my 
software because of it.  -Wall has found bugs, valgrind/gdb have helped 
me find bugs, but never have I ran splint on my code base and actually 
found a bug.

Maybe your situation is different, and I don't dismiss that.

> I deeply appreciate that GCC has taken on incorporating (sensible) lint-like
> functionality into the compiler itself, which uses -Wfoo toggles.  (I can
> even appreciate that -Wall is "select popular warnings", and -Wextra is
> "select additional less popular warnings".)
>
> Right now, I have a command-line for GCC g++ that is very, very, very, very
> long, because I enable the warnings I know about.  But I may have missed one
> or two.  And more may come out with the next version of GCC that I am
> unaware about.
>
> I wish I had a -Weverything flag.
>   
I'd be more interested in better static analysis than more syntax 
warnings.  And GCC has done a bit of that, if for example, you use a 
constant in an array index for an array of known dimensions GCC will 
warn if the value is out of range.  Things like that are more useful I'd 
think.

I guess it also depends on your work flow standards too.  Where I work 
our standards are basically reasonably close to ISO C (except where we 
start doing kernel or embedded work), and pass with the standard set of 
"-Wall -W" flags without warnings. 

Not to say we're 100% defect free, but of the (few) defects we have had, 
extra syntax checks would not have found them.  Typically they'd be 
things like structure size mismatches, off by one errors, etc.

> As long as I'm making wishes, I also wish warnings were emitted like this:
> test.cpp:6: -Wunused warning: unused variable 'u'
> ...rather than...
> test.cpp:6: warning: unused variable 'u'
>
> Just my $0.02.
>   
Perhaps a variant of that where it outputs a code instead and you can 
look it up in a manpage so the output isn't as verbose, e.g.

test.cpp:6: (W43) warning: blah

Where W43 refers to -Wunused or something.

If you want to get on about formatting though, it would be nice to give 
gcc a "I'm in 2009 with an ANSI VT100 terminal can you please highlight 
text for me" option so that file names, line numbers, and the warning 
appear in different colours allowing them to be scanned relatively quickly.

:-)

Tom

Re: Where did the warning go?

[John (Eljay) Love-Jensen]

Hi everyone,

[Tom]> I think most long term developers really just want the warnings for
two things.  Things that are undefined behaviour, and things that are likely
a typo...

I don¹t mind keeping -Wall with the current meaning, and not deprecating it.

I, as a long term developer who has been developing for over 30 years, and
in C/C++ for over 20 years, using GCC since 2.95 came out, do wish that
there was a -Weverything flag that enabled all -W* toggle warnings.

Why?

Because I use GCC as a lint-like tool.

I like to be able to see what warnings my code generates, vet those warnings
and vet my code, then decide to disable the warning or fix my code.

I deeply appreciate that GCC has taken on incorporating (sensible) lint-like
functionality into the compiler itself, which uses -Wfoo toggles.  (I can
even appreciate that -Wall is "select popular warnings", and -Wextra is
"select additional less popular warnings".)

Right now, I have a command-line for GCC g++ that is very, very, very, very
long, because I enable the warnings I know about.  But I may have missed one
or two.  And more may come out with the next version of GCC that I am
unaware about.

I wish I had a -Weverything flag.

As long as I'm making wishes, I also wish warnings were emitted like this:
test.cpp:6: -Wunused warning: unused variable 'u'
...rather than...
test.cpp:6: warning: unused variable 'u'

Just my $0.02.

Sincerely,
--Eljay

Re: Where did the warning go?

[Tom St Denis]

Eivind LM wrote:
> On Tue, 24 Feb 2009 18:57:58 +0100, Harvey Chapman 
> <hchapman-gcc-help@3gfp.com> wrote:
>
>> Ian Lance Taylor wrote:
>>> The name -Wall was chosen some 20 years ago.  Perhaps it was a mistake,
>>> however it was decided, and documented, and has been used successfully,
>>> for a long time.  I think it would take a very persuasive argument to
>>> change it now.  That argument would need to be more than merely "the
>>> name doesn't seem right for what it does."  You need to consider the
>>> cost of changing all the Makefiles out there which use it, and the
>>> benefits of making the change.
>>>
>> Why not change it to -Wmost or -Wpopular and then mark -Wall as 
>> deprecated for 3-5 years before removal. I would think that would be 
>> a reasonable time frame for such a change with so much history. Or 
>> just leave -Wall as-is, and just discourage further use via a 
>> deprecated warning.
>
> Deprecation sounds like a great idea. If I have a vote for new name, 
> then I give it to "-Wselect-popular-warnings" as suggested by Eljay.
>
> I can think of three groups of people who would benefit from the 
> deprecation:
>
> 1) People who use the flag and believe that it actually means all 
> warnings. Why check the docs on something so obvious? These people 
> will be happy about the deprecation because it will make them realize 
> that there are more warnings they can enable.
I've been using GCC since '96 or so.  I've always understood "-Wall" to 
mean all relevant warnings, not every possible warning but the ones that 
are deemed reasonable to find bugs in code.

> 2) People who have read the docs and are confused about the name (I am 
> in this group now). These people will keep asking questions about the 
> name unless it is deprecated.

Or they can learn from experience that "every possible warning under the 
sun" is not actually a good thing, and then stop asking for that 
functionality.

> 3) People who know the docs by heart and don't really think it matters 
> if the name says something else than what it does. These people won't 
> have to explain the flag over and over again for people from group 2.
I'm more interested in not breaking GCC.  If my projects start building 
with 1000s of useless warnings it means I'll have to either "fix" them 
in the code (useless casts, etc) or disable them in my makefile.  And 
instead of just having -Wall -W I'd have "-Wall -Wno-stupid-warning1 
-Wno-stuipid-warning2 .... 100 chars more ... -Wno-stupid-warning100".

I think most long term developers really just want the warnings for two 
things.  Things that are undefined behaviour, and things that are likely 
a typo, e.g.

if (a = 4)

or

if (a << 1 + b)

etc...

> Other arguments:
>
> 1) The name says "all", while the flag does not enable all.
It enables all useful flags, where "useful" is subjective but from what 
I understand means "likely to flag real problems."  Your flaw in your 
reasoning is you think additional "scrutiny" is meaningful in the face 
of a well understood standard.

> 2) The flag might change between versions. So some warnings included 
> in the flag might be removed, whereas the name suggests that it 
> includes at least everything you had before.
That's at least a reasonable concern. 

> 3) Because it seems like a lot of people agree that the name is not 
> right, and has proven to cause confusion.
Wait till you have 10-15-20 years of development under your belt.  Your 
attitude will change.

> 4) It's not an argument to keep it even if it might have been 
> inconsistent for 20 years.
I don't know, it's served people well.

> 5) Deprecating it would avoid confusion with a possible future flag 
> that might actually enable all warnings.
And require [albeit trivial] changes to software for no net gain.

> 6) I might be running out of arguments, but I will buy you a beer once 
> it is deprecated, Ian :)
Learn C, then buy the beer. 

To me "-Wall" should reflect all warnings that are likely to result in 
the undesired behaviour.  For things (like the type promotions you 
posted earlier) where there is a clearly defined behaviour, it's less 
desirable.

Sure in the expression (a << 1 + b) we know that + has precedence over 
<<, but this is a classic typo people make when they probably meant (a 
<< 1) + b.  So that's worthy, in my opinion, of a warning.

Whereas, something like

float a = 4;
or
char b = 'c';

Are not since it's without a doubt clear what it means.  And if your 
only argument for more warnings is that you're unsure of the language 
standard, then you need to re-evaluate what you're asking. 

Tom

Re: Where did the warning go?

[Eivind LM]

On Tue, 24 Feb 2009 18:52:32 +0100, Ian Lance Taylor <iant@google.com>  
wrote:

> "Eivind LM" <eivliste@online.no> writes:
>
>> It does of course depend on each case whether a warning is easy to
>> avoid  or not, and also if it warns about a real problem or not. But
>> in any case,  a warning can help me write code that more surely will
>> do what I intend.  For example the following code is not doing what I
>> intended:
>>
>>   #include <stdio.h>
>>   void print(int a) { printf("%d\n", a); };
>>   int main() { print(2.5); return 0; };
>>
>> I think the problem in the code is both easy to avoid and serious, but
>> I  get no warning with -Wall and -Wextra (g++ 4.3).
>>
>> Instead of adding -Wconversion (and to search for any other flags I
>> might  find useful, but that I don't know of yet), I would rather
>> compile my  project with something like "-Weverything" from the
>> beginning, and then  disable the warnings that turns out to not fit my
>> programming style.
>
> I think the issue here is that there is disagreement about whether the
> -Wconversion warnings rise to the level of being questionable.  It would
> be reasonable to propose having -Wconversion under -Wall, if you want to
> send in a proposed patch.  It might be interesting to try building some
> packages with such a change, notably gcc itself.

Maybe everything implied with -Wconversion is too much. But the code above  
gave me a warning with g++ 4.1 (even without any flags to g++ at all). So  
seems like these kinds of warnings are not new as defaults to gcc.

However, seems like 4.1 without flags gives less warnings than 4.3 with  
the -Wconversion flag, so it might seem like only parts of -Wconversion  
were included in 4.1.

For example this statement needs -Wconversion with 4.1 to create a warning:

   float b = 123456789000;

So maybe I'm asking for only parts of -Wconversion to be included in  
-Wall. Anyway, I'm afraid I will have to climb a few more steps in C  
before I'm ready to submit patches to gcc :) Thanks for listening to my  
opinions anyway.

Eivind

Re: Where did the warning go?

[Eivind LM]

On Tue, 24 Feb 2009 18:57:58 +0100, Harvey Chapman  
<hchapman-gcc-help@3gfp.com> wrote:

> Ian Lance Taylor wrote:
>> The name -Wall was chosen some 20 years ago.  Perhaps it was a mistake,
>> however it was decided, and documented, and has been used successfully,
>> for a long time.  I think it would take a very persuasive argument to
>> change it now.  That argument would need to be more than merely "the
>> name doesn't seem right for what it does."  You need to consider the
>> cost of changing all the Makefiles out there which use it, and the
>> benefits of making the change.
>>
> Why not change it to -Wmost or -Wpopular and then mark -Wall as  
> deprecated for 3-5 years before removal. I would think that would be a  
> reasonable time frame for such a change with so much history. Or just  
> leave -Wall as-is, and just discourage further use via a deprecated  
> warning.

Deprecation sounds like a great idea. If I have a vote for new name, then  
I give it to "-Wselect-popular-warnings" as suggested by Eljay.

I can think of three groups of people who would benefit from the  
deprecation:

1) People who use the flag and believe that it actually means all  
warnings. Why check the docs on something so obvious? These people will be  
happy about the deprecation because it will make them realize that there  
are more warnings they can enable.

2) People who have read the docs and are confused about the name (I am in  
this group now). These people will keep asking questions about the name  
unless it is deprecated.

3) People who know the docs by heart and don't really think it matters if  
the name says something else than what it does. These people won't have to  
explain the flag over and over again for people from group 2.


Other arguments:

1) The name says "all", while the flag does not enable all.

2) The flag might change between versions. So some warnings included in  
the flag might be removed, whereas the name suggests that it includes at  
least everything you had before.

3) Because it seems like a lot of people agree that the name is not right,  
and has proven to cause confusion.

4) It's not an argument to keep it even if it might have been inconsistent  
for 20 years.

5) Deprecating it would avoid confusion with a possible future flag that  
might actually enable all warnings.

6) I might be running out of arguments, but I will buy you a beer once it  
is deprecated, Ian :)

Eivind

Re: Where did the warning go?

[Eivind LM]

On Tue, 24 Feb 2009 19:28:59 +0100, Tom St Denis  
<tstdenis@ellipticsemi.com> wrote:

> Eivind LM wrote:
>> On Tue, 24 Feb 2009 15:13:55 +0100, Tom St Denis  
>> <tstdenis@ellipticsemi.com> wrote:
>>
>>> Eivind LM wrote:
>>>> It does of course depend on each case whether a warning is easy to  
>>>> avoid or not, and also if it warns about a real problem or not. But  
>>>> in any case, a warning can help me write code that more surely will  
>>>> do what I intend. For example the following code is not doing what I  
>>>> intended:
>>>>
>>>>   #include <stdio.h>
>>>>   void print(int a) { printf("%d\n", a); };
>>>>   int main() { print(2.5); return 0; };
>>>>
>>>> I think the problem in the code is both easy to avoid and serious,  
>>>> but I get no warning with -Wall and -Wextra (g++ 4.3).
>>> That's because it's not undefined behaviour.  "default" warnings  
>>> should be for things that are not guaranteed to have a known meaning  
>>> or behaviour.
>>
>> I think the warning should be part of -Wall, but I understand if you  
>> don't agree. Anyway this is not my point. I trust someone has good  
>> reasons for the selection of warnings included in -Wall.
> Because warnings for things that have defined behaviour [and aren't  
> specifically likely to be wrong] are annoying, see "splint" for examples  
> of useless warnings.

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.

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.

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

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.

Introducing a new name for -Wall, deprecating -Wall, and introducing  
-Weverything sounds like a great idea to me.

>
>>> int a;
>>> if (a == 4) { ... }
>>>
>>> Is undefined behaviour since a is unitialized.
>>
>> Compiling this example with -Wall and -Wextra gives me no warning with  
>> g++ (Debian 4.3.2-1.1) 4.3.2. Installed by apt-get today from Debian  
>> repositories.
>
> You have to turn on the optimizer for the warning to come out (otherwise  
> the compiler can't detect it's uninitialized).

Thanks for the advice! I found the documentation now that you mention it.  
I guess it could be a topic for another discussion wether it is reasonable  
that an optimization flag changes the warning output.

>>> float a;
>>> a = 0;
>>> if (a == 4) { ... }
>>>
>>> Is fine, but I should also point out "4" is an integral type that is  
>>> converted to float for the purpose of the expression "a == 4" .  So by  
>>> your logic, it should also generate a warning.
>>
>> Yes, I would like a warning if I compare a float to an int.
> Why?  It's perfectly valid (well yeah not the == bit, but try a > 4).

Because the value of the int might change when implicitly casted to float.  
Looks like the -Wconversion flag gives me such warnings in many cases. But  
not in this example:

#include <stdio.h>

int main() {
   float  f = 16777216; // 2^24
   int    i = 16777217; // 2^24 + 1

   if( i > f ) printf( "i > f\n" );
   else printf( "i <= f\n" );

   return 0;
}

>
>> I would probably not compare two floats on equality anyway, but if I  
>> really had to, then I would write "4" as 4.0f.
>
> You should learn about type promotion.

You mean type promotion as in "implicit conversions that preserve values"?  
I'm not asking for warnings for implicit conversions when the values are  
preserved.

> That's like saying
>
> long a;
> a = 3;
>
> Should be a warning since I didn't write 3L or (long)3.

For me, the big difference is between implicit conversions that preserve  
values and those that don't preserve values. I would like to have a  
warning unless it is 100% sure that my value is the same after the  
implicit conversion.

Like in my example at the top, where 2.5 was converted to 2. If I wanted  
to loose the decimals, then I would have casted the value myself.

>>> -Wall should really just enable every warning that has something to do  
>>> with behaviour that is not predictable.
>>
>> Fine, but the name should be changed.
> I dunno, there are a lot of people who use -Wall -W and rely on the fact  
> that the warnings it produces are USEFUL not just chatty.

Keeping the flag as deprecated, and introducing a new flag with the same  
function but different name should make everyone happy.

Eivind

Re: Where did the warning go?

[Tom St Denis]

Eivind LM wrote:
> On Tue, 24 Feb 2009 15:13:55 +0100, Tom St Denis 
> <tstdenis@ellipticsemi.com> wrote:
>
>> Eivind LM wrote:
>>> It does of course depend on each case whether a warning is easy to 
>>> avoid or not, and also if it warns about a real problem or not. But 
>>> in any case, a warning can help me write code that more surely will 
>>> do what I intend. For example the following code is not doing what I 
>>> intended:
>>>
>>>   #include <stdio.h>
>>>   void print(int a) { printf("%d\n", a); };
>>>   int main() { print(2.5); return 0; };
>>>
>>> I think the problem in the code is both easy to avoid and serious, 
>>> but I get no warning with -Wall and -Wextra (g++ 4.3).
>> That's because it's not undefined behaviour.  "default" warnings 
>> should be for things that are not guaranteed to have a known meaning 
>> or behaviour.
>
> I think the warning should be part of -Wall, but I understand if you 
> don't agree. Anyway this is not my point. I trust someone has good 
> reasons for the selection of warnings included in -Wall.
Because warnings for things that have defined behaviour [and aren't 
specifically likely to be wrong] are annoying, see "splint" for examples 
of useless warnings.


>> int a;
>> if (a == 4) { ... }
>>
>> Is undefined behaviour since a is unitialized.
>
> Compiling this example with -Wall and -Wextra gives me no warning with 
> g++ (Debian 4.3.2-1.1) 4.3.2. Installed by apt-get today from Debian 
> repositories.

You have to turn on the optimizer for the warning to come out (otherwise 
the compiler can't detect it's uninitialized).

>> float a;
>> a = 0;
>> if (a == 4) { ... }
>>
>> Is fine, but I should also point out "4" is an integral type that is 
>> converted to float for the purpose of the expression "a == 4" .  So 
>> by your logic, it should also generate a warning.
>
> Yes, I would like a warning if I compare a float to an int.
Why?  It's perfectly valid (well yeah not the == bit, but try a > 4).


> I would probably not compare two floats on equality anyway, but if I 
> really had to, then I would write "4" as 4.0f.

You should learn about type promotion. 

That's like saying

long a;
a = 3;

Should be a warning since I didn't write 3L or (long)3.

>> -Wall should really just enable every warning that has something to 
>> do with behaviour that is not predictable.
>
> Fine, but the name should be changed.
I dunno, there are a lot of people who use -Wall -W and rely on the fact 
that the warnings it produces are USEFUL not just chatty.

Tom

Re: Where did the warning go?

[Harvey Chapman]

Ian Lance Taylor wrote:
> The name -Wall was chosen some 20 years ago.  Perhaps it was a mistake,
> however it was decided, and documented, and has been used successfully,
> for a long time.  I think it would take a very persuasive argument to
> change it now.  That argument would need to be more than merely "the
> name doesn't seem right for what it does."  You need to consider the
> cost of changing all the Makefiles out there which use it, and the
> benefits of making the change.
>    
Why not change it to -Wmost or -Wpopular and then mark -Wall as 
deprecated for 3-5 years before removal. I would think that would be a 
reasonable time frame for such a change with so much history. Or just 
leave -Wall as-is, and just discourage further use via a deprecated warning.

Re: Where did the warning go?

[Ian Lance Taylor]

"Eivind LM" <eivliste@online.no> writes:

> On Mon, 23 Feb 2009 21:39:18 +0100, Ian Lance Taylor <iant@google.com>
> wrote:
>
>> "Eivind LM" <eivliste@online.no> writes:
>>
>>> Next question: Does the -Wall flag have a long and complicated history?
>>
>> No, though certainly the details have changed over time.
>
> So the flag enables a subset of all warnings, and the collection
> changes  over time. Why don't the name reflect that? I think Eljay's
> suggested name  "-Wselect-popular-warnings" was excellent.

The name -Wall was chosen some 20 years ago.  Perhaps it was a mistake,
however it was decided, and documented, and has been used successfully,
for a long time.  I think it would take a very persuasive argument to
change it now.  That argument would need to be more than merely "the
name doesn't seem right for what it does."  You need to consider the
cost of changing all the Makefiles out there which use it, and the
benefits of making the change.


> It does of course depend on each case whether a warning is easy to
> avoid  or not, and also if it warns about a real problem or not. But
> in any case,  a warning can help me write code that more surely will
> do what I intend.  For example the following code is not doing what I
> intended:
>
>   #include <stdio.h>
>   void print(int a) { printf("%d\n", a); };
>   int main() { print(2.5); return 0; };
>
> I think the problem in the code is both easy to avoid and serious, but
> I  get no warning with -Wall and -Wextra (g++ 4.3).
> 
> Instead of adding -Wconversion (and to search for any other flags I
> might  find useful, but that I don't know of yet), I would rather
> compile my  project with something like "-Weverything" from the
> beginning, and then  disable the warnings that turns out to not fit my
> programming style.

I think the issue here is that there is disagreement about whether the
-Wconversion warnings rise to the level of being questionable.  It would
be reasonable to propose having -Wconversion under -Wall, if you want to
send in a proposed patch.  It might be interesting to try building some
packages with such a change, notably gcc itself.

Ian

Re: Where did the warning go?

[Kevin P. Fleming]

John (Eljay) Love-Jensen wrote:

> I have asked for that feature in the past, on this forum, but did not meet
> with any interest amongst the GCC developers, nor any interest (at that
> time*) from other GCC users.  For the self-same reasons expressed in this
> recent discussion.
> 

<snip>

> * Now there is both of us!  :-)

Add the Asterisk development community's voice to that bandwagon as
well; we have had many cases where developers compiling Asterisk on
different platforms saw warnings that others did not see, and even
though we have -Werror turned on and a buildbot system to check for
errors and warnings, it does not catch everything because we rely on
-Wall and -Wextra to be 'enough'. Given this discussion, we'll have to
modify our build system to supply explicit -W flags for all the warnings
we care about in 'addition' to -Wall, just in case they get removed from
-Wall in a future GCC release.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: kpfleming@digium.com
Check us out at www.digium.com & www.asterisk.org

Re: Where did the warning go?

[John (Eljay) Love-Jensen]

Hi Eivind,

> If -Weverything is impossible, then I wish a flag that enables every
> single warning that might be relevant for my programming style. Probably
> others would want this for their programming styles too. But if there are
> too many different programming styles to have -Weverything-style-*, then
> how about having -Weverything anyway, and let people disable warnings that
> don't fit with their style?

CAVEAT:

-Weverything (were it to be incorporated) would only enable toggle flag
warnings.  It would not enable exceeded threshold warnings (since those
warnings have to be supplied a threshold parameter) or parameter based
warnings (since those warnings require a parameter).

I, for one, am entirely in favor of a -Weverything flag, and then explicitly
opt-out, ala -Wno-foo, on a case-by-case basis.

I have asked for that feature in the past, on this forum, but did not meet
with any interest amongst the GCC developers, nor any interest (at that
time*) from other GCC users.  For the self-same reasons expressed in this
recent discussion.

Of course, there's always the GCC is open source, add the flag yourself
option.  (I do often build my own GCC, but I don't normally fiddle with the
source code.)

Sincerely,
--Eljay

* Now there is both of us!  :-)

Re: Where did the warning go?

[Eivind LM]

On Tue, 24 Feb 2009 15:13:55 +0100, Tom St Denis  
<tstdenis@ellipticsemi.com> wrote:

> Eivind LM wrote:
>> It does of course depend on each case whether a warning is easy to  
>> avoid or not, and also if it warns about a real problem or not. But in  
>> any case, a warning can help me write code that more surely will do  
>> what I intend. For example the following code is not doing what I  
>> intended:
>>
>>   #include <stdio.h>
>>   void print(int a) { printf("%d\n", a); };
>>   int main() { print(2.5); return 0; };
>>
>> I think the problem in the code is both easy to avoid and serious, but  
>> I get no warning with -Wall and -Wextra (g++ 4.3).
> That's because it's not undefined behaviour.  "default" warnings should  
> be for things that are not guaranteed to have a known meaning or  
> behaviour.

I think the warning should be part of -Wall, but I understand if you don't  
agree. Anyway this is not my point. I trust someone has good reasons for  
the selection of warnings included in -Wall.

My points are: "-Wall" should be renamed, and a new flag should be added  
that would enable absolutely all warnings.

> e.g.
>
> int a;
> if (a == 4) { ... }
>
> Is undefined behaviour since a is unitialized.

Compiling this example with -Wall and -Wextra gives me no warning with g++  
(Debian 4.3.2-1.1) 4.3.2. Installed by apt-get today from Debian  
repositories.

> float a;
> a = 0;
> if (a == 4) { ... }
>
> Is fine, but I should also point out "4" is an integral type that is  
> converted to float for the purpose of the expression "a == 4" .  So by  
> your logic, it should also generate a warning.

Yes, I would like a warning if I compare a float to an int.

I would probably not compare two floats on equality anyway, but if I  
really had to, then I would write "4" as 4.0f.

Compiling the second example with -Wall and -Wextra gives me no warning  
with the same compiler as above.

> -Wall should really just enable every warning that has something to do  
> with behaviour that is not predictable.

Fine, but the name should be changed.

> -Weverything would be an appropriate name for every warning.

Agree! :)

Eivind

Re: Where did the warning go?

[Tom St Denis]

Eivind LM wrote:
> It does of course depend on each case whether a warning is easy to 
> avoid or not, and also if it warns about a real problem or not. But in 
> any case, a warning can help me write code that more surely will do 
> what I intend. For example the following code is not doing what I 
> intended:
>
>   #include <stdio.h>
>   void print(int a) { printf("%d\n", a); };
>   int main() { print(2.5); return 0; };
>
> I think the problem in the code is both easy to avoid and serious, but 
> I get no warning with -Wall and -Wextra (g++ 4.3).
That's because it's not undefined behaviour.  "default" warnings should 
be for things that are not guaranteed to have a known meaning or behaviour.

e.g.

int a;
if (a == 4) { ... }

Is undefined behaviour since a is unitialized.

float a;
a = 0;
if (a == 4) { ... }

Is fine, but I should also point out "4" is an integral type that is 
converted to float for the purpose of the expression "a == 4" .  So by 
your logic, it should also generate a warning.

-Wall should really just enable every warning that has something to do 
with behaviour that is not predictable.

-Weverything would be an appropriate name for every warning.

Tom

Re: Where did the warning go?

[Eivind LM]

On Mon, 23 Feb 2009 21:39:18 +0100, Ian Lance Taylor <iant@google.com>  
wrote:

> "Eivind LM" <eivliste@online.no> writes:
>
>> Next question: Does the -Wall flag have a long and complicated history?
>
> No, though certainly the details have changed over time.

So the flag enables a subset of all warnings, and the collection changes  
over time. Why don't the name reflect that? I think Eljay's suggested name  
"-Wselect-popular-warnings" was excellent.

>> The name indicates that it enables ... well, uh, ... *all* warnings.  
>> (Yes,
>> i should have read the docs more carefully.)
>
> As the docs say, -Wall enables all warnings which can be easily avoided
> by changing the soure code.

It is useful to have a flag like that, but the the name should really be  
something else than -Wall.

>> I would like to compile my code with absolutely as many compiler  
>> warnings
>> enabled as possible, and then selectively deactivate the ones that I
>> cannot avoid in a reasonable way.
>
> That is pretty much the goal of -Wall.
>
> The warnings which are not included in -Wall are either difficult to
> avoid in some cases or are specific to certain programming styles.

It does of course depend on each case whether a warning is easy to avoid  
or not, and also if it warns about a real problem or not. But in any case,  
a warning can help me write code that more surely will do what I intend.  
For example the following code is not doing what I intended:

   #include <stdio.h>
   void print(int a) { printf("%d\n", a); };
   int main() { print(2.5); return 0; };

I think the problem in the code is both easy to avoid and serious, but I  
get no warning with -Wall and -Wextra (g++ 4.3).

Instead of adding -Wconversion (and to search for any other flags I might  
find useful, but that I don't know of yet), I would rather compile my  
project with something like "-Weverything" from the beginning, and then  
disable the warnings that turns out to not fit my programming style.

>> Is there a way to enable absolutely all? -Weverything? :)
>
> No, that would not be useful.  Nobody writes code in the intersection of
> all the programming styles supported by all the warning options.

I am sure you are right about this, so maybe -Weverything is not the right  
thing. But my point is that it is better to start off with "everything",  
and disable the ones you don't want for a given project, than to start  
with only a selected set of warnings.

Because if you are using -Wall then:
a) You don't know which warnings you are missing out on.
b) You might risk loosing a warning you were used to have (unless you are  
always reading the changelog for new gcc versions)

> We are certainly open to changing the ways that the warnings are
> aggregated into -Wall and -Wextra, including adding a new aggregation
> warning if it seems useful.  However, -Weverything is unlikely to be
> accepted.

If -Weverything is impossible, then I wish a flag that enables every  
single warning that might be relevant for my programming style. Probably  
others would want this for their programming styles too. But if there are  
too many different programming styles to have -Weverything-style-*, then  
how about having -Weverything anyway, and let people disable warnings that  
don't fit with their style?

I'm glad to hear that you are open for changes, and also very grateful  
that you took the time to reply thoroughly to my email.

Thanks,
Eivind
PS, did I mention that -Wall should be renamed? :)

Re: Where did the warning go?

[Ian Lance Taylor]

"Eivind LM" <eivliste@online.no> writes:

> Next question: Does the -Wall flag have a long and complicated history?

No, though certainly the details have changed over time.

> The name indicates that it enables ... well, uh, ... *all* warnings. (Yes,
> i should have read the docs more carefully.)

As the docs say, -Wall enables all warnings which can be easily avoided
by changing the soure code.

> I would like to compile my code with absolutely as many compiler warnings
> enabled as possible, and then selectively deactivate the ones that I
> cannot avoid in a reasonable way.

That is pretty much the goal of -Wall.

The warnings which are not included in -Wall are either difficult to
avoid in some cases or are specific to certain programming styles.

> Is there a way to enable absolutely all? -Weverything? :)

No, that would not be useful.  Nobody writes code in the intersection of
all the programming styles supported by all the warning options.

We are certainly open to changing the ways that the warnings are
aggregated into -Wall and -Wextra, including adding a new aggregation
warning if it seems useful.  However, -Weverything is unlikely to be
accepted.

Ian

RE: Where did the warning go?

[John (Eljay) Love-Jensen]

Hi Eivind,

> Next question: Does the -Wall flag have a long and complicated history? The name indicates that it enables ... well, uh, ... *all* warnings. (Yes, i should have read the docs more carefully.)

One might think that "-Wall" is all warnings.  But it is not.  Maybe a better name would be "-Wselect-popular-warnings".

> Is there a way to enable absolutely all? -Weverything? :)

No.  You have to enable the warnings one-by-one.  The -Wall and -Wextra will enable sets of warnings en masse.

It would be nice to have a -Wall-and-I-mean-it-dammit-this-time-with-feeling for the toggle warnings (precluding the parameter warnings).  Then you could -Wno-conversion opt-out of the warnings as you see fit, explicitly.  But, alas, that's not available

Sincerely,
--Eljay

Re: Where did the warning go?

[Eivind LM]

On Sat, 14 Feb 2009 03:24:41 +0100, Ian Lance Taylor <iant@google.com>
wrote:

> "Eivind LM" <eivliste@online.no> writes:
>
>> So the problem seems to be that my g++-4.1 includes the -Wconversion
>> by  default, while the others don't. Is the set of default warnings
>> known to  vary between versions and platforms?
>
> The warning options don't vary between platforms.  They do vary between
> versions.
>
> See, e.g., http://gcc.gnu.org/gcc-4.3/changes.html which mentions a
> change to -Wconversion.

The changelog mentions a change in the way -Wconversion works, it does not
mention that -Wconversion is not anymore a part of -Wall. Anyway, my
observation was that warnings about conversion were included in version
4.1, and not in 4.2, so the change should be mentioned in the 4.2
changelog. I cannot find it there though. This is not a problem for me
anymore though (after I found the -Wconversion flag), it just seems odd.


Next question: Does the -Wall flag have a long and complicated history?
The name indicates that it enables ... well, uh, ... *all* warnings. (Yes,
i should have read the docs more carefully.)

I would like to compile my code with absolutely as many compiler warnings
enabled as possible, and then selectively deactivate the ones that I
cannot avoid in a reasonable way. Once upon a time I found a flag with a
convincing name (-Wall). Then after a while I found a new flag which
gave me more warnings (-Wextra). Then now I realized that -Wconversion is  
not
included even if i use -Wall and -Wextra.

Is there a way to enable absolutely all? -Weverything? :)

Eivind

Re: Where did the warning go?

[Ian Lance Taylor]

"Eivind LM" <eivliste@online.no> writes:

> So the problem seems to be that my g++-4.1 includes the -Wconversion
> by  default, while the others don't. Is the set of default warnings
> known to  vary between versions and platforms?

The warning options don't vary between platforms.  They do vary between
versions.

See, e.g., http://gcc.gnu.org/gcc-4.3/changes.html which mentions a
change to -Wconversion.

Ian

Re: Where did the warning go?

[Eivind LM]

Thank you for your quick and helpful reply, Eljay! I added the  
-Wconversion flag, and then the warning appeared as I wanted in all g++  
versions on my system :)

So the problem seems to be that my g++-4.1 includes the -Wconversion by  
default, while the others don't. Is the set of default warnings known to  
vary between versions and platforms?

Eivind

On Fri, 13 Feb 2009 17:26:17 +0100, John (Eljay) Love-Jensen  
<eljay@adobe.com> wrote:

> Hi Eivind,
>
> Worked for me.  I didn't have the exact versions of GCC you were using,  
> though.
>
> Did you specify -Wconversion?
>
> Sincerely,
> --Eljay
>
>

RE: Where did the warning go?

[John (Eljay) Love-Jensen]

Hi Eivind,

Worked for me.  I didn't have the exact versions of GCC you were using, though.

Did you specify -Wconversion?

Sincerely,
--Eljay

Where did the warning go?

[Eivind Lyche Melvær]

Greetings,
The code below used to (and should, in my opinion) generate a warning  
about implicit conversion. I have tried four different versions of g++:

   g++ 4.1.3 20080704 (prerelease) (Debian 4.1.2-25)
   g++ 4.2.4 (Debian 4.2.4-6)
   g++ 4.3.2 (Debian 4.3.2-1.1)
   g++ 4.3.3

Only the oldest version (4.1.3) gives me the warning that I'm after:

   warning: passing ‘double’ for argument 1 to ‘void print(int)’

The other three versions give no warning at all, even though I compile  
with -Wall and -Wextra. So it looks like the warnings disappeared  
somewhere after version 4.1.3. Is this a bug? Or is there a way to enable  
these warnings in the more recent versions of g++?

Thanks,
Eivind LM


#include <iostream>

void print(int number) {
   std::cout << number << std::endl;
}

int main() {

   double d = 1.5;
   print(d);
   return 0;

}