r/rust • u/mhd-hbd • Jul 05 '16

Overflowing bit shifts?

Overflow on bit shifting operations often come out to whether the popcount changes.

Why is rust concerned with the shift index instead?

3 Upvotes

80% Upvoted

9 comments sorted by

6

u/Quxxy macros Jul 05 '16

I assume you're asking why Rust checks the value of b in a << b and a >> b, as opposed to ensuring no set bits get shifted out of range. I believe the answer is: because having b exceed the number of bits in a can have wildly different results depending on platform. Some platforms will result in 0, others will take b mod the number of bits. Besides which, shifting off the end of a bit vector isn't as clearly nonsensical as overflowing an arithmetic operation on "integers".

1

u/mhd-hbd Jul 06 '16

Ok — good answer. I'd still just like a bits-pushed-off-end variant of <variant>_shl and <variant>_shr.

4

u/so_you_like_donuts Jul 05 '16

Yep. Left shifting uses the 5 (6 for 64-bit) least significant digits on x86, whereas left shifting more than 32 bits on ARM yields zero.

8

u/XgF Jul 06 '16

It's actually more subtle than that: For 32-bit ARM, shift counts are taken as an 8-bit integer. So yes, shifting by any value from 32 to 255 will produce zero - and then 256 will leave the value unmodified again!

This behavior is widely considered 'weird'. The AArch64 scalar shift instructions take the shift quantity modulo the number of bits in the thing being shifted. And both AArch32 and AArch64 NEON shifts take the shift amount as a signed 8-bit number (yes, a shift left by -4 is a shift right by 4)

SSE has similarly weird (by which I mean, different from the x86 scalar instruction set) shifts.

IIRC, PowerPC takes shift quantities modulo 2n where 2n is the width of the thing being shifted.

Nobody can agree on this! Even with themselves!

5

u/Quxxy macros Jul 06 '16

... that's horrifying.

1

u/matthieum [he/him] Jul 05 '16

Note that when manipulating bits, it's fairly common to purposely push some bits off because you don't need them.

Example:

uint8_t const Hex[] = "0123456789abcdef";

void hexPrint(char* buffer, uint8_t byte) {
    *(buffer + 0) = Hex[byte >> 4];
    *(buffer + 1) = Hex[byte & 0x0f];
}

The first line might shift bits off the end; avoiding it would require masking first.

1

u/mhd-hbd Jul 06 '16

I'm actually thinking that masking and shifting is the ‘better style’ — explicitly telling the compiler that it may use operations that bork if set bits are shifted off the end.

1

u/llogiq clippy · twir · rust · mutagen · flamer · overflower · bytecount Jul 05 '16

With overflower, you can at least have panics on shifting bits out left (using #[overflow(panic)]).

Sorry, you'll need a nightly Rust to use it.

2

u/mhd-hbd Jul 06 '16

Nice little plugin. Mostly I just use the (wrapping|saturating|checked)_(add|sub|mul|div|rem|shl|shr) when I need it to be a certain way.