Re: -Wconversion versus libstdc++

[Gabriel Dos Reis <gdr at cs dot tamu dot edu>]

On Wed, 17 Jan 2007, Joe Buck wrote:

| On Wed, Jan 17, 2007 at 04:36:04PM -0600, Gabriel Dos Reis wrote:
| > I just built firefox (CVS) with GCC mainline.  The compiler spitted
| > avalanches of non-sensical warning about conversions signed ->
| > unsigned may alter values, when in fact the compiler knows that
| > such things cannot happen.
| >
| > First, let's recall that GCC supports only 2s complement targets.
| >
| > Second, a conversion from T to U may alter value if a round trip is
| > not the identity function.  That is, there exists a value t in T
| > such that the assertion
| >
| >    assert (T(U(t)) == t)
| >
| > fails.
| >
| > Now, given a signed integer type T, and U as unsigned variant, there
| > is no way the above can happen, given the characteristics of GCC.
| > There many of this "may alter value" business is pure noise.
|
| Careful.  As you suggest, let's restrict ourselves to two's complement
| platforms.  I would want the compiler to warn if the identity holds for an
| ILP32 machine but not an LP64 machine, even if I'm running on an ILP32.
| But if the two types are going to be the same size everywhere (because one
| is the unsigned modifier of the other) then GCC should not complain.

The specific cases I'm concerned about here (and if you have a chance
to build firefox for example, you'll see) is when T and U differ only
in signedness, that is

   T = int, U = unsigned
   T = long, U = unsigned long
   T = long long, U = unsigned long long

those have the same value representation bits and there is no way, GCC
can mess up -- except bugs in the compiler itself.

Furthermore, elsewhere (in the overflow thread) it has been suggested
that people should convert to the unsigned variants, do computations there,
and convert back to the signed variants.  We have just promised an
invariant that we will hold.

-- Gaby