[EMAIL PROTECTED] (Martin v. Löwis) writes:
> No. In that case, ptrdiff_t most likely would be an integral type with
> 42.69 bits, and conversion to int would cause loss of
> precision. Matteo requests that a warning is issued for size kind of
> conversion (probably also from size_t to int), as on some systems,
> sizeof(ptrdiff_t) > sizeof(int). That would be something like
> -W64bit-portability.
Thanks for clarifying what I was trying to say.
Yes, it would be nice if there were a flag -W64bit-portability that
warns about constructs that behave differently in 32bit and 64bit
machines.
Besides { ptrdiff_t, size_t, long } -> int conversions, another
potential source of trouble is the following. Assume
double *p;
unsigned index;
int stride;
Consider the expression
p[index * stride]
If index == 1 and stride == -1, this expression means p[-1] on ILP32
machines, and p[0xFFFFFFFF] on LP64 machines. It is unlikely that
this was the intended behavior of the code.
(Because int * unsigned is evaluated as unsigned, p[index * stride]
means
*(p + (ptrdiff_t) ( index * (unsigned) stride ))
and the conversion unsigned -> ptrdiff_t zero-extends the result to 64
bits.)
Cheers,
Matteo
