* Where did the warning go?
@ 2009-02-13 16:07 Eivind Lyche Melvær
2009-02-13 16:27 ` John (Eljay) Love-Jensen
0 siblings, 1 reply; 27+ messages in thread
From: Eivind Lyche Melvær @ 2009-02-13 16:07 UTC (permalink / raw)
To: gcc-help
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;
}
^ permalink raw reply [flat|nested] 27+ messages in thread
* RE: Where did the warning go?
2009-02-13 16:07 Where did the warning go? Eivind Lyche Melvær
@ 2009-02-13 16:27 ` John (Eljay) Love-Jensen
2009-02-13 17:57 ` Eivind LM
0 siblings, 1 reply; 27+ messages in thread
From: John (Eljay) Love-Jensen @ 2009-02-13 16:27 UTC (permalink / raw)
To: Eivind Lyche Melvær, gcc-help
Hi Eivind,
Worked for me. I didn't have the exact versions of GCC you were using, though.
Did you specify -Wconversion?
Sincerely,
--Eljay
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Where did the warning go?
2009-02-13 16:27 ` John (Eljay) Love-Jensen
@ 2009-02-13 17:57 ` Eivind LM
2009-02-14 2:25 ` Ian Lance Taylor
0 siblings, 1 reply; 27+ messages in thread
From: Eivind LM @ 2009-02-13 17:57 UTC (permalink / raw)
To: gcc-help
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
>
>
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Where did the warning go?
2009-02-13 17:57 ` Eivind LM
@ 2009-02-14 2:25 ` Ian Lance Taylor
2009-02-20 15:39 ` Eivind LM
0 siblings, 1 reply; 27+ messages in thread
From: Ian Lance Taylor @ 2009-02-14 2:25 UTC (permalink / raw)
To: Eivind LM; +Cc: gcc-help
"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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Where did the warning go?
2009-02-14 2:25 ` Ian Lance Taylor
@ 2009-02-20 15:39 ` Eivind LM
2009-02-20 16:21 ` John (Eljay) Love-Jensen
2009-02-23 20:39 ` Ian Lance Taylor
0 siblings, 2 replies; 27+ messages in thread
From: Eivind LM @ 2009-02-20 15:39 UTC (permalink / raw)
To: gcc-help
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* RE: Where did the warning go?
2009-02-20 15:39 ` Eivind LM
@ 2009-02-20 16:21 ` John (Eljay) Love-Jensen
2009-02-23 20:39 ` Ian Lance Taylor
1 sibling, 0 replies; 27+ messages in thread
From: John (Eljay) Love-Jensen @ 2009-02-20 16:21 UTC (permalink / raw)
To: Eivind LM, gcc-help
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Where did the warning go?
2009-02-20 15:39 ` Eivind LM
2009-02-20 16:21 ` John (Eljay) Love-Jensen
@ 2009-02-23 20:39 ` Ian Lance Taylor
2009-02-24 14:03 ` Eivind LM
1 sibling, 1 reply; 27+ messages in thread
From: Ian Lance Taylor @ 2009-02-23 20:39 UTC (permalink / raw)
To: Eivind LM; +Cc: gcc-help
"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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Where did the warning go?
2009-02-23 20:39 ` Ian Lance Taylor
@ 2009-02-24 14:03 ` Eivind LM
2009-02-24 14:13 ` Tom St Denis
` (2 more replies)
0 siblings, 3 replies; 27+ messages in thread
From: Eivind LM @ 2009-02-24 14:03 UTC (permalink / raw)
To: gcc-help
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? :)
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Where did the warning go?
2009-02-24 14:03 ` Eivind LM
@ 2009-02-24 14:13 ` Tom St Denis
2009-02-24 15:10 ` Eivind LM
2009-02-24 15:43 ` John (Eljay) Love-Jensen
2009-02-24 17:52 ` Ian Lance Taylor
2 siblings, 1 reply; 27+ messages in thread
From: Tom St Denis @ 2009-02-24 14:13 UTC (permalink / raw)
To: Eivind LM; +Cc: gcc-help
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Where did the warning go?
2009-02-24 14:13 ` Tom St Denis
@ 2009-02-24 15:10 ` Eivind LM
2009-02-24 18:29 ` Tom St Denis
0 siblings, 1 reply; 27+ messages in thread
From: Eivind LM @ 2009-02-24 15:10 UTC (permalink / raw)
To: gcc-help
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Where did the warning go?
2009-02-24 14:03 ` Eivind LM
2009-02-24 14:13 ` Tom St Denis
@ 2009-02-24 15:43 ` John (Eljay) Love-Jensen
2009-02-24 15:52 ` Kevin P. Fleming
2009-02-24 17:52 ` Ian Lance Taylor
2 siblings, 1 reply; 27+ messages in thread
From: John (Eljay) Love-Jensen @ 2009-02-24 15:43 UTC (permalink / raw)
To: Eivind LM, GCC-help
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! :-)
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Where did the warning go?
2009-02-24 15:43 ` John (Eljay) Love-Jensen
@ 2009-02-24 15:52 ` Kevin P. Fleming
0 siblings, 0 replies; 27+ messages in thread
From: Kevin P. Fleming @ 2009-02-24 15:52 UTC (permalink / raw)
Cc: GCC-help
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Where did the warning go?
2009-02-24 14:03 ` Eivind LM
2009-02-24 14:13 ` Tom St Denis
2009-02-24 15:43 ` John (Eljay) Love-Jensen
@ 2009-02-24 17:52 ` Ian Lance Taylor
2009-02-24 17:58 ` Harvey Chapman
2009-02-25 0:37 ` Eivind LM
2 siblings, 2 replies; 27+ messages in thread
From: Ian Lance Taylor @ 2009-02-24 17:52 UTC (permalink / raw)
To: Eivind LM; +Cc: gcc-help
"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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Where did the warning go?
2009-02-24 17:52 ` Ian Lance Taylor
@ 2009-02-24 17:58 ` Harvey Chapman
2009-02-25 0:23 ` Eivind LM
2009-02-25 0:37 ` Eivind LM
1 sibling, 1 reply; 27+ messages in thread
From: Harvey Chapman @ 2009-02-24 17:58 UTC (permalink / raw)
To: gcc-help
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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Where did the warning go?
2009-02-24 15:10 ` Eivind LM
@ 2009-02-24 18:29 ` Tom St Denis
2009-02-25 0:07 ` Eivind LM
0 siblings, 1 reply; 27+ messages in thread
From: Tom St Denis @ 2009-02-24 18:29 UTC (permalink / raw)
To: Eivind LM; +Cc: gcc-help
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Where did the warning go?
2009-02-24 18:29 ` Tom St Denis
@ 2009-02-25 0:07 ` Eivind LM
0 siblings, 0 replies; 27+ messages in thread
From: Eivind LM @ 2009-02-25 0:07 UTC (permalink / raw)
To: Tom St Denis; +Cc: gcc-help
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Where did the warning go?
2009-02-24 17:58 ` Harvey Chapman
@ 2009-02-25 0:23 ` Eivind LM
2009-02-25 12:09 ` Tom St Denis
0 siblings, 1 reply; 27+ messages in thread
From: Eivind LM @ 2009-02-25 0:23 UTC (permalink / raw)
To: gcc-help
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Where did the warning go?
2009-02-24 17:52 ` Ian Lance Taylor
2009-02-24 17:58 ` Harvey Chapman
@ 2009-02-25 0:37 ` Eivind LM
1 sibling, 0 replies; 27+ messages in thread
From: Eivind LM @ 2009-02-25 0:37 UTC (permalink / raw)
To: gcc-help
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Where did the warning go?
2009-02-25 0:23 ` Eivind LM
@ 2009-02-25 12:09 ` Tom St Denis
2009-02-25 12:25 ` John (Eljay) Love-Jensen
0 siblings, 1 reply; 27+ messages in thread
From: Tom St Denis @ 2009-02-25 12:09 UTC (permalink / raw)
To: Eivind LM; +Cc: gcc-help
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Where did the warning go?
2009-02-25 12:09 ` Tom St Denis
@ 2009-02-25 12:25 ` John (Eljay) Love-Jensen
2009-02-25 13:02 ` Tom St Denis
` (2 more replies)
0 siblings, 3 replies; 27+ messages in thread
From: John (Eljay) Love-Jensen @ 2009-02-25 12:25 UTC (permalink / raw)
To: GCC-help
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Where did the warning go?
2009-02-25 12:25 ` John (Eljay) Love-Jensen
@ 2009-02-25 13:02 ` Tom St Denis
2009-02-25 13:17 ` Andrew Haley
2009-02-25 21:48 ` Ian Lance Taylor
2 siblings, 0 replies; 27+ messages in thread
From: Tom St Denis @ 2009-02-25 13:02 UTC (permalink / raw)
To: John (Eljay) Love-Jensen; +Cc: GCC-help
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Where did the warning go?
2009-02-25 12:25 ` John (Eljay) Love-Jensen
2009-02-25 13:02 ` Tom St Denis
@ 2009-02-25 13:17 ` Andrew Haley
2009-02-25 21:48 ` Ian Lance Taylor
2 siblings, 0 replies; 27+ messages in thread
From: Andrew Haley @ 2009-02-25 13:17 UTC (permalink / raw)
To: GCC-help
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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Where did the warning go?
2009-02-25 12:25 ` John (Eljay) Love-Jensen
2009-02-25 13:02 ` Tom St Denis
2009-02-25 13:17 ` Andrew Haley
@ 2009-02-25 21:48 ` Ian Lance Taylor
2 siblings, 0 replies; 27+ messages in thread
From: Ian Lance Taylor @ 2009-02-25 21:48 UTC (permalink / raw)
To: John (Eljay) Love-Jensen; +Cc: GCC-help
"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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Where did the warning go?
2009-02-25 16:16 ` Tom St Denis
@ 2009-02-25 17:16 ` John Z. Bohach
0 siblings, 0 replies; 27+ messages in thread
From: John Z. Bohach @ 2009-02-25 17:16 UTC (permalink / raw)
To: gcc-help
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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Where did the warning go?
2009-02-25 15:56 ` Eivind LM
@ 2009-02-25 16:16 ` Tom St Denis
2009-02-25 17:16 ` John Z. Bohach
0 siblings, 1 reply; 27+ messages in thread
From: Tom St Denis @ 2009-02-25 16:16 UTC (permalink / raw)
To: Eivind LM; +Cc: gcc-help
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Where did the warning go?
2009-02-25 14:20 ` Tom St Denis
@ 2009-02-25 15:56 ` Eivind LM
2009-02-25 16:16 ` Tom St Denis
0 siblings, 1 reply; 27+ messages in thread
From: Eivind LM @ 2009-02-25 15:56 UTC (permalink / raw)
To: Tom St Denis; +Cc: gcc-help
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Where did the warning go?
2009-02-25 13:53 ` Eivind LM
@ 2009-02-25 14:20 ` Tom St Denis
2009-02-25 15:56 ` Eivind LM
0 siblings, 1 reply; 27+ messages in thread
From: Tom St Denis @ 2009-02-25 14:20 UTC (permalink / raw)
To: Eivind LM; +Cc: gcc-help
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
^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2009-02-25 21:48 UTC | newest]
Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-02-13 16:07 Where did the warning go? Eivind Lyche Melvær
2009-02-13 16:27 ` John (Eljay) Love-Jensen
2009-02-13 17:57 ` Eivind LM
2009-02-14 2:25 ` Ian Lance Taylor
2009-02-20 15:39 ` Eivind LM
2009-02-20 16:21 ` John (Eljay) Love-Jensen
2009-02-23 20:39 ` Ian Lance Taylor
2009-02-24 14:03 ` Eivind LM
2009-02-24 14:13 ` Tom St Denis
2009-02-24 15:10 ` Eivind LM
2009-02-24 18:29 ` Tom St Denis
2009-02-25 0:07 ` Eivind LM
2009-02-24 15:43 ` John (Eljay) Love-Jensen
2009-02-24 15:52 ` Kevin P. Fleming
2009-02-24 17:52 ` Ian Lance Taylor
2009-02-24 17:58 ` Harvey Chapman
2009-02-25 0:23 ` Eivind LM
2009-02-25 12:09 ` Tom St Denis
2009-02-25 12:25 ` John (Eljay) Love-Jensen
2009-02-25 13:02 ` Tom St Denis
2009-02-25 13:17 ` Andrew Haley
2009-02-25 21:48 ` Ian Lance Taylor
2009-02-25 0:37 ` Eivind LM
2009-02-25 0:23 Tom St Denis
2009-02-25 13:53 ` Eivind LM
2009-02-25 14:20 ` Tom St Denis
2009-02-25 15:56 ` Eivind LM
2009-02-25 16:16 ` Tom St Denis
2009-02-25 17:16 ` John Z. Bohach
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).