Implementing safe shift-left - c++

Question

I would like to implement a shift-left function that would trigger a failure upon overflow.
Here is my code:
uint32_t safe_shl(uint32_t x, uint8_t y) {
uint32_t z = x << y;
assert((z >> y) == x);
return z;
}
Please assume that I the assert function registers an error in my system.
I would like to ensure that my method is bullet-proof (i.e., fails on every erroneous input and only on erroneous input).
And I would also like to ask if you know of a more efficient way to implement this (assuming that it is indeed bullet-proof).

Answer 1

If x << y is undefined, all bets are off.
The only safe way is to check that it's a valid shift before attempting it.
uint32_t safe_shl(uint32_t x, uint8_t y) {
assert (y < 32);
if (y < 32)
{
uint32_t z = x << y;
assert((z >> y) == x);
return z;
}
return 0;
}
Note that you need the condition – shifting unconditionally lets the compiler assume that y < 32 is true.

Answer 2

Step 1. If x == 0and any shift amount, the result is conceptually still 0 and is not a problem.
Step 2. Do not attempt excessive shifts.
If the value of the right operand is negative or greater than or equal to the width of the promoted left operand, the behavior is undefined. C11 §6.5.7 3
Step 3. Insure unsigned math while shifting.
If int/unsigned is wider than uintN_t x, then x << y is done with int math. This is rare with N==32 yet possible. Signed math overflow is possible and leads to UB. By 1u*x or (0u+x), code can insure the shift uses the wider of unsigned and uintN_t math. Good compilers will still make optimal code.
Step 4. Detect if a reduction occurred.
If E1 has an unsigned type, the value of the result is E1 × 2E2, reduced modulo
one more than the maximum value representable in the result type §6.5.7 4
uint32_t safe_shl(uint32_t x, uint8_t y) {
if (x == 0) {
return 0;
}
assert(y < 32);
uint32_t z = (1u*x) << y;
assert((z >> y) == x);
return z;
}

Answer 3

Are you asking to assert if the shift would cause a carry?
In which case it's a bit nasty in c++ without resorting to intrinsics or assembler.
#include <cassert>
#include <cstdint>
#include <limits>
bool shl_would_carry(uint32_t x, uint8_t y)
{
constexpr auto nof_bits = std::numeric_limits<decltype(x)>::digits;
if (y >= nof_bits)
{
if (x != 0) return true;
}
else
{
auto limit = decltype(x)(1) << (nof_bits - y);
if (x >= limit) return true;
}
return false;
}
uint32_t safe_shl(uint32_t x, uint8_t y)
{
assert(!shl_would_carry(x, y));
return x << y;
}
I think that's right.
This might be better:
std::tuple<uint32_t, uint32_t> shl(uint32_t x, uint8_t y)
{
uint32_t overflow, result;
constexpr auto nof_bits = std::numeric_limits<decltype(x)>::digits;
overflow = x >> (nof_bits - y);
result = x << y;
return std::make_tuple(overflow, result);
}
uint32_t safe_shl(uint32_t x, uint8_t y)
{
auto t = shl(x, y);
assert(!std::get<0>(t));
return std::get<1>(t);
}

Answer 4

In C, x << y if defined for uint32_t provided y < 32. From the n1570 draft for C11 in 6.5.7 Bitwise shift operators:
If the value of the right operand is negative or is greater than or equal to the width of the promoted left operand, the behavior is undefined.
The result in then required to be: x × 2y, reduced modulo
one more than the maximum value representable in the result type
Let call that value z like it is in your proposed code. Like you use an unsigned type the value of z >> y is required to be the integral part of z/2y.
That means that provided y < 32 if there is an overflow, the value of z >> y will be strictly less than x because of the modulo, and if there is non overflow, you get exactly x
Full reference from 6.5.7 Bitwise shift operators:
...4 The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated bits are filled with
zeros. If E1 has an unsigned type, the value of the result is E1 × 2E2, reduced modulo
one more than the maximum value representable in the result type. If E1 has a signed
type and nonnegative value, and E1 × 2E2 is representable in the result type, then that is
the resulting value; otherwise, the behavior is undefined.
5 The result of E1 >> E2 is E1 right-shifted E2 bit positions. If E1 has an unsigned type
or if E1 has a signed type and a nonnegative value, the value of the result is the integral
part of the quotient of E1 / 2E2. If E1 has a signed type and a negative value, the
resulting value is implementation-defined.
It is exactly the same in C++ from n4296 draft for C++14 in 5.8 Shift operators [expr.shift]:
...The behavior is undefined if the right operand
is negative, or greater than or equal to the length in bits of the promoted left operand.
2 The value of E1 << E2 is E1 left-shifted E2 bit positions; vacated bits are zero-filled. If E1 has an unsigned
type, the value of the result is E1 × 2E2, reduced modulo one more than the maximum value representable
in the result type. Otherwise, if E1 has a signed type and non-negative value, and E1×2E2 is representable
in the corresponding unsigned type of the result type, then that value, converted to the result type, is the
resulting value; otherwise, the behavior is undefined.
3 The value of E1 >> E2 is E1 right-shifted E2 bit positions. If E1 has an unsigned type or if E1 has a signed
type and a non-negative value, the value of the result is the integral part of the quotient of E1/2E2. If E1
has a signed type and a negative value, the resulting value is implementation-defined.
So in both languages, and assuming that the assert function registers an error in [your] system, code should be:
uint32_t safe_shl(uint32_t x, uint8_t y) {
assert(y<32);
uint32_t z = x << y;
assert((z >> y) == x);
return z;
}

Answer 5

In order to write a safe function, you must first identify what isn't safe. If you don't do this, the task is nonsense. The kind of "overflow" you mention is actually well-defined. But the following cases of dangerous behavior exist:
Left-shifting further than the size of the variable, including shifting data into the sign bit of a signed variable. (Undefined behavior)
The the right operator is a negative number. (Undefined behavior)
Right-shifting a negative number. (Impl.-defined behavior)
Implicit integer promotion of the left operand causing it to silently change signedness and thereby invoking one of the above errors.
To avoid this, you need to ensure that:
The left operand must be unsigned.
The right operand must be valid and in range of the type of the left operand.
The left operand must not be a small integer type.
1) and 3) are solved by using uint32_t. There exist no system where uint32_t is smaller than int.
2) is solved by using an unsigned type and checking that it isn't too large.
In addition, you seem to have a requirement that shifting out of bounds of the left operand should not be allowed. This is weird, but ok, lets implement that too. It can be done by checking if the MSB bit position plus the number of shifts are larger than 31.
uint8_t msb_pos32 (uint32_t data)
{
uint8_t result = 0;
while(data>>=1 > 0)
{
result++;
}
return result;
}
uint32_t safe_LSL32 (uint32_t x, uint8_t y)
{
if(y > 31 || y+msb_pos32(x) > 31)
{
__asm HCF; // error handling here
}
return x << y;
}
Note that this code can be further optimized.