On Dec 3, 3:59 am, elliot.li.t...@ gmail.com wrote:
On Nov 12, 5:35 pm, James Kanze <james.ka...@gm ail.comwrote:
On Nov 12, 5:53 am, Rolf Magnus <ramag...@t-online.dewrote:
elliot.li.t...@ gmail.com wrote:
I've tried options "-m64 -pedantic -Wall -Wextra -std=c++98" on both
x86-64 and PPC64, neither issued a single waring on assigning a "long"
to "int."
You are right. I could have sworn that there is a warning for that, but I
looked into the manual and didn't find any option that gets me such a
warning. You could ask in gnu.g++.help, but it seems to me there is no
warning for that.
The problem is that it would also warn on things like:
char* p ;
int ch = getchar() ;
if ( ch != EOF ) {
*p ++ = ch ;
// ...
}
or even:
short a, b, c ;
a = b + c ;
The first is an extremely common idiom in C, and is probably
used in quite a lot of C++ code as well. The second will occur
anytime arithmetic is done on short or character types, because
of integral promotion.
Yes, I agree with you on this. These scenarios shouldn't trigger
warnings in _default_ compiler warning level. So my question should be
about 64-bit porting only, ie. it would be better for me if GCC
supported some thing like -Wporting that includes porting related
warnings, such as this assign-long-to-int thing.
That's a special case. Sun CC generates a number of warnings in
64 bit mode, when it thinks that the semantics of the program
might be different than they would be in 32 bit mode. I've not
found them very useful, however.
The utility of the warning may be less that you might think,
too. An expression like:
int a, b, c ;
a = b + c ;
is probably even more common, and has the same risks.
I think overflow-checking and warning-on-implicit-conversion are
different games. Not checking for overflow is a good of C/C++.
Allowing unspecified behavior is good? How can that be?
If we need it, we can just write our own Int and overload the
operator+() to do the checking.
At a very, very high runtime cost; the checking is expensive.
If the compiler did it, all it needs to do is check the overflow
status flag after the addition. Very, very cheap.
To be really useful, of course, you'd want some sort of global
optimization. If I'm doing something like:
int d1 = rand() % 6 + 1 ;
int d2 = rand() % 6 + 1 ;
int throw = d1 + d2 ;
overflow checking on that final addition really isn't necessary.
A good compiler should be able to recognize this, and suppress
it. And of course, you'd also want to suppress it if you had
something like:
int d1 = throwDice() ; // post-condition: return value in
int d2 = throwDice() ; // range [1..6].
int throw = d1 + d2 ;
Which means the compiler must do inter-module analysis.
Alternatively, a pragma could be used to turn it off locally, if
the profiler showed it necessary.
And also it would be good if the compiler supports warnings on
porting specific errors.
You mean, for example, any time you suppose an int is more than
16 bits? Or your code depends on it being 2's complement?
Sun CC supports warnings for porting from 32 bit to 64 bit,
because the compiler was 32 bit (and only 32 bit) for the
longest time. Their warnings are only relevant to users of the
older compilers, when porting their code to the newer one. They
concern customers of a specific compiler; they are not designed
to be general portability warnings. I'm not sure what should be
included in general portability warnings; most programs really
don't have to be 100% portable (e.g. to a 1's complement 36 bit
machine).
--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
