This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Where did the warning go?


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]