Inaccuracies in the reference about bitshifts and overflows

[simias]

The references states that >> is a logical right shift, however it seems that it behaves like an arithmetic right shift for signed integers. For instance the following snippet prints -2:

let i = -4i32;

println!("{}", i >> 1);

A logical right shift should produce 2147483646 (assuming 2's complement representation which I think rust guarantees?).

In the same spirit the reference does not say if shifting outside the range of an integer is defined. From my quick test it doesn't appear to be:

let i = 10u32;
let j = 200u32;

println!("{}", i << j);

This prints garbage on my computer and on the playpen, so I assume it's UB or at least UV (it doesn't trigger the overflow check in debug builds though, maybe it should?)

On a similar topic the reference also states that the following behaviours are safe:

• Unsigned integer overflow (well-defined as wrapping)
• Signed integer overflow (well-defined as two's complement representation wrapping)

I believe that's not true anymore.

[simias]

I see that checking for bitshift overflows is going to be implemented in #22020 so it seems to confirm that it's UB (UV?) for now.

[pnkfelix]

see PR #23536 for the checks. We can go either way on the issue of whether overflow is UB or UV or neither. (That is, it is easy to adapt the PR accordingly; just a matter of deciding, and perhaps measuring the impact on code size, maybe.)

[steveklabnik]

@pnkfelix what's the process by which we decide that? I'd like to knock this issue out.

[pnkfelix]

@steveklabnik heh, I already made an "executive decision" (though admittedly it was one that @nikomatsakis was already in favor of), of making overflow panic when checks are on, and when the checks are off, we forcibly mask the RHS to ensure that we do not encounter weirdness such as that documented in #10183 and #23551.

(Though I still need to put in tests for that fallback behavior.)

[simias]

That sounds very reasonable, thanks.

Right shifts of signed values will remain arithmetic though, right? It's probably what most people will expect since that's how it's done in C/C++ and we'd have to simple way of doing arithmetic shifting otherwise.

[pnkfelix]

@simias right-shift of signed values are still arithmetic shifts, but that is independent of the overflow checking (which is based solely on the value of the right-hand-side compared to the bitwidth of the type of the left-hand-side)

[simias]

Okay, that makes sense. I wanted to make sure that was the intended behaviour since the reference seems to say otherwise.

Thank you!

[pnkfelix]

@simias oh I see; yes that part of the reference has probably been incorrect for a long time.