Date: Sun, 27 Oct 2013 20:24:54 -0700
On 10/25/13, Richard Smith <richardsmith_at_[hidden] wrote:
> On Oct 25, 2013, Jeffrey Yasskin <jyasskin_at_[hidden]> wrote:
> > Nope: [expr.shift]p1 says, "The type of the result is that
> > of the promoted left operand."
>
> I believe John is correct. 5.8/1 says we perform *integral
> promotions* on the operands, not the *usual arithmetic
> conversions*. Clang, g++, and EDG agree -- the type of
> (unsigned char)0 << 0u is int.
Sigh, I think promoting unsigned to signed is broken, but I do
not think we can change it. Does any compiler have a warning
for this behavior?
> > However, I think p2 saves our intrepid developer in C++14:
> > "Otherwise, if E1 has a signed type and non-negative value,
> > and E1 × 2^E2 is representable in the corresponding unsigned
> > type of the result type, then that value, converted to the
> > result type, is the resulting value;"
>
> We gave this defined behavior as a DR, so I view this code has
> having de facto defined behavior in C++11 and C++98 too. But
> it's UB in C.
Can you point to the DR? I cannot find it.
> In other words, we've already fixed this one (for some value
> of "fixed").
Right, we defined it to be what people were getting already.
While I think that was the only really practical choice, I would
rather see a less permissive option available to programmers
that do not want to stray from "mathematically expected" results.
> On Oct 25, 2013, Jeffrey Yasskin <jyasskin_at_[hidden]> wrote:
> > Nope: [expr.shift]p1 says, "The type of the result is that
> > of the promoted left operand."
>
> I believe John is correct. 5.8/1 says we perform *integral
> promotions* on the operands, not the *usual arithmetic
> conversions*. Clang, g++, and EDG agree -- the type of
> (unsigned char)0 << 0u is int.
Sigh, I think promoting unsigned to signed is broken, but I do
not think we can change it. Does any compiler have a warning
for this behavior?
> > However, I think p2 saves our intrepid developer in C++14:
> > "Otherwise, if E1 has a signed type and non-negative value,
> > and E1 × 2^E2 is representable in the corresponding unsigned
> > type of the result type, then that value, converted to the
> > result type, is the resulting value;"
>
> We gave this defined behavior as a DR, so I view this code has
> having de facto defined behavior in C++11 and C++98 too. But
> it's UB in C.
Can you point to the DR? I cannot find it.
> In other words, we've already fixed this one (for some value
> of "fixed").
Right, we defined it to be what people were getting already.
While I think that was the only really practical choice, I would
rather see a less permissive option available to programmers
that do not want to stray from "mathematically expected" results.
-- Lawrence Crowl
Received on 2013-10-28 04:24:57