On Tue, 24 Feb 2009 19:28:59 +0100, Tom St Denis
<tstdenis@xxxxxxxxxxxxxxxx> wrote:
Eivind LM wrote:
On Tue, 24 Feb 2009 15:13:55 +0100, Tom St Denis
<tstdenis@xxxxxxxxxxxxxxxx> 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
