Are the result of bitwise operations on signed integral types well-defined?

Question

Consider this code:

using integer = int; // or any other fundamental integral type
using unsigned_integer = typename std::make_unsigned<integer>::type;
constexpr integer bits = std::numeric_limits<unsigned_integer>::digits;
integer value = -42; // or any value
integer mask = static_cast<integer>(1)<<static_cast<integer>(bits-1);
bool result_and = value & mask;
bool result_or = value | mask;
bool result_xor = value ^ mask;

I am wondering how well are these operations defined according to the standard. Do I have the guarantee to end up with the same results on all architectures? I am sure to operate on the sign bit on all architectures where this sign bit is 0 for positive numbers and 1 for negative numbers?

Answer 1

The results of bitwise and, bitwise or and bitwise xor are currently underspecified in the standard, in particular the term bitwise is never defined. We have defect report 1857: Additional questions about bits that covers this issue and says:

The specification of the bitwise operations in 5.11 [expr.bit.and], 5.12 [expr.xor], and 5.13 [expr.or] uses the undefined term “bitwise” in describing the operations, without specifying whether it is the value or object representation that is in view.

Part of the resolution of this might be to define “bit” (which is otherwise currently undefined in C++) as a value of a given power of 2.

and the resolution was:

CWG decided to reformulate the description of the operations themselves to avoid references to bits, splitting off the larger questions of defining “bit” and the like to issue 1943 for further consideration.

Which resulted in a consolidated defect report 1943: Unspecified meaning of “bit”.

The result of left shifting a signed type is going to depend on the underlying representation. We can see this from the defect report 1457: Undefined behavior in left-shift which made it well defined to left shift into the sign bit and says:

The current wording of 5.8 [expr.shift] paragraph 2 makes it undefined behavior to create the most-negative integer of a given type by left-shifting a (signed) 1 into the sign bit, even though this is not uncommonly done and works correctly on the majority of (twos-complement) architectures:

...if E1 has a signed type and non-negative value, and E1 ⨯ 2E2 is representable in the result type, then that is the resulting value; otherwise, the behavior is undefined.

As a result, this technique cannot be used in a constant expression, which will break a significant amount of code.

Noting the emphasis on the statement works correctly on the majority of (twos-complement) architectures. So it is dependent on the underlying representation for example twos-complement.

Answer 2

Regarding left and right shift operators, from the C++ standard section 5.8:

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.

Then it says that the left shift operator E1 << E2 results in an undefined behavior when all of the following conditions are satisfied:

• The left operand has a signed type.
• Either the left operand has a negative value or it has a non-negative value such that E1 × 2^E2 is not representable in the resulting type.

Also regarding the right shift operator E1 >> E2, the behavior is implementation-dependent if the left operand has signed type and a negative value.

The bitwise AND, XOR and OR operators are well-defined for all integral types. This is specified in sections 5.11, 5.12 and 5.13, respectively.

However, note that the the representation of signed integral values can be either Two's complement, Ones' complement or signed magnitude. Most compilers use the Two's complement representation though. These include gcc, VC++, icl and Clang.

Answer 3

Operators &, | and ^ are bitwise, and deal with individual bits, so they will do exactly what you written: apply the mask.

Left shift << operator is a bit trickier. It will lead to undefined behavior if you shift negative value or if you shift 1 to sign bit position or beyond.

static_cast<integer>(1)<<static_cast<integer>(bits-1);

It seems you shift 1 to sign bit position there, and it is undefined behavior.