Seems strange to me that
Produces no warnings on GCC 4.2.3 even with "-Wall -pedantic -ansi".Code:int a = 1.5;
I thought GCC used to warn me about that? (possible loss of precision)... Or am I remembering stuff from Java?
Printable View
Seems strange to me that
Produces no warnings on GCC 4.2.3 even with "-Wall -pedantic -ansi".Code:int a = 1.5;
I thought GCC used to warn me about that? (possible loss of precision)... Or am I remembering stuff from Java?
Do you have compiler warnings turned off in the build options? I know codeblocks has an option for "inhibit all warning messages". Just a thought.
I'm calling gcc(g++) directly from the command line.
the gcc documentation says this falls under a category enabled with "-Wextra" (and -Wall does not include this)
It's strange. "-Wexta" doesn't work either... I've also never heard of this flag.Code:#include <stdio.h>
int main(void) {
int a = 1.5;
fprintf(stdout, "%f\n%d\n", a, a);
return 0;
}
Code:bill@bill-laptop:~$ gcc -Wextra -pedantic -ansi test.c
bill@bill-laptop:~$ ./a.out
0.000000
1
A large number of programmers don't bother with an explicit cast when causing a floating point truncation. There are huge amounts of code out there which would produce zillions of warnings if this were always reported. The GCC creators have decided that in this case, the programmer knows best, and does not warn.
Visual C++ does warn for this implicit conversion. Maybe that is what you are recalling.
Ah, I see.
I am pretty sure I have never used Visual C++ in my life.
Guess it must've been from Java.
With Mingw (3.4.2) the warnings seem different for C and C++: one warns about the conversion, the other warns about the wrong parameters to fprintf (with -Wall and -Wextra).
why is it listed in their documentation that these warnings will be displayed if "-Wextra" is used? is it a bug? do you have to somehow request or build your own "verbose" gcc?
I know this is somewhat of a broader interpretation of the standard, but in affect this sort of behavior is compliant. A language called D exists, and in D a variable becomes a float in this circumstance. The attitude about this situation in D is that what the programmer wrote knows best, even if it was a typo.
GCC 4.1.2 gives me a warning for all three truncating assignments with -Wall -Wextra -pedantic -ansi:
Code:int main()
{
double d = 1.5;
int i1 = 1.5;
int i2 = d;
i1 = d;
}
I am surprised to tell the truth! Think of this, compiled with -Wall -Wextra in gcc:
Warning for overflow on line 7. Correct. Now delete line 7. No warning!! And wrong result of course on printf() ...Code:#include <stdio.h>
#include <stdlib.h>
#include <string.h>
int main(void) {
double d; int i;
i = 21231231231; //line 7
d = 21231231231;
i = d;
printf("%d",i);
return 0;
}
Why would it let you do this? Aside for truncating the decimals from a floating number, double can store bigger numbers than the maximum integer. Why not HAVE to cast at least? You will have the same result, don't get me wrong. But lets say that you write a huge program and you don't think that i is a double. You will get an error. If you HAD to cast then you would get a compiler error.
It is also the whole idea. Types are types, they shouldn't be mixed that easily, no matter the logic behind it.
Anyway, g++ gives you warnings
Quote:
GCC 4.1.2 gives me a warning for all three truncating assignments with -Wall -Wextra -pedantic -ansi:
Code:int main()
{
double d = 1.5;
int i1 = 1.5;
int i2 = d;
i1 = d;
}
Strange...Quote:
cyberfish@cyberfish-desktop:/tmp$ gcc -Wall -Wextra -pedantic -ansi test.c
test.c: In function ‘main’:
test.c:5: warning: unused variable ‘i2’
test.c:7: warning: control reaches end of non-void function
cyberfish@cyberfish-desktop:/tmp$ gcc -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7)
cyberfish@cyberfish-desktop:/tmp$
To be more precise, I compile with -Wall -Wextra and -std=gnu99. If I don't include -std=gnu99 I get one warning "int constant is too large for "long" type". Don't know what that means.Quote:
Originally Posted by C_ntua
If I change the value of d to 1 and exclude line 7 and compile with -Wall -Wextra -ansi -pedantic I get no warnings...
I just kind see the "logic" behind it. And, seriously, I cannot see the "logic" for not having a warning when you give -Wall and/or -Wextra...
"int constant is too large for "long" type"
My guess on the warning is: you are trying to assign (or initialize) a number which is too large for the long data type to hold. Like trying to assign a 64-bit number to a 32-bit data type.
Well, I only use double and int though, but I suppose it means the double. Is the actual number too long for double (don't remember ranges)?
No it is not.
It is with 32-bit longs, as in 32-bit systems. According to the rules of the standard, the compiler has to see if it fits into a int, and if not, try a long. If that also doesn't fit, the behaviour is, I believe, undefined. Or perhaps implementation-defined. The point is, since some platforms GCC compiles for have larger longs than ints, it really tries them in order - and when it fails, it reports that the literal won't fit into a long, since that's the last thing it tried.
I'm still confused as to why your GCC doesn't give any warnings.