Why does bit operation on integer types smaller than 4 bytes behave unexpectedly?

Question

Please consider the code example where I want to check if all bits in a unsigned integer variable are set. IntegerType is replaced by uint8_t, uint16_t, uint32_t uint64_t.

The question: Why does the assertion succeed for IntegerType = uint32_t and uint64_t while it fails for uint16_t and uint8_t?

#include <cstdint>
#include <cassert>

IntegerType bitset = -1; // set all bits to true

IntegerType t = ~bitset;
bool bAllBitsSet1 = (t == 0);
bool bAllBitsSet2 = ((~bitset) == 0);

assert(bAllBitsSet1 == bAllBitsSet2);

related/dupe: https://stackoverflow.com/questions/30473958/what-is-going-on-with-bitwise-operators-and-integer-promotion — NathanOliver, May 10 '18 at 18:23
At least GCC emits a `warning: promoted ~unsigned is always non-zero [-Wsign-compare]`. — HolyBlackCat, May 10 '18 at 18:24
The constant value minus 1 is always of type int. Your assignment does an implicit cast which might not do what you expect — JVApen, May 10 '18 at 18:25
Assigning -1 to unsigned integer types is a common way to produce the largest unsigned value. See http://www.cplusplus.com/reference/string/string/npos/ — Fabian, May 10 '18 at 18:40

score 5 · Accepted Answer · answered May 10 '18 at 18:30

5

This happens due to integer promotion: the first expression casts ~bitset back into the shorter type, while the second expression uses full integer value.

For integer types shorter than int the value gets promoted to int before performing an operation, in this case, before applying ~ to it.

Consider uint16_t for an example. When you write

uint16_t t = ~bitset;

the value of bitset gets promoted to int, so it becomes 0x0000FFFF on a 32-bit platform. Then ~ is applied, producing 0xFFFF0000. Finally, the result gets written back into t, chopping off high bits. Therefore, t is zero.

On the other hand, when you compare ~bitset to zero directly, the comparison fails, because 0xFFFF0000 is not zero.

answered May 10 '18 at 18:30

Sergey Kalinichenko

714,442
84
1,110
1,523

Does promotion preserve the signed/unsigned property? Also, why does promotion take place anyway? – Fabian May 10 '18 at 18:42
@Fabian Promotion does not preserve the sign. If `int` can represent all values of a type, the expression gets converted to `int`. My best guess as to why this is done this way is that it's done to save CPU cycles: CPUs often operate on `int`s because they lack corresponding instructions for shorter types, so if the standard required casting back to short int, this would force compilers emit instructions that are seldom needed. Since you are given an option to keep the `int` or to cast it back, standard writers decided against requiring universal truncation. – Sergey Kalinichenko May 10 '18 at 18:48
" why does promotion take place anyway?" because that the way this language works https://en.cppreference.com/w/cpp/language/implicit_conversion – Slava May 10 '18 at 19:01

Why does bit operation on integer types smaller than 4 bytes behave unexpectedly?

1 Answers1

Linked