C++ Logo


Advanced search

Re: [ub] ub due to left operand of shift

From: Lawrence Crowl <Lawrence_at_[hidden]>
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.

Lawrence Crowl

Received on 2013-10-28 04:24:57