Fixing std::bit_cast of types
with padding bits

Contents

1. Introduction

Surprisingly, the undefined behavior in such cases does not depend on the argument. A specialization std::bit_cast<To, From> is an alternative spelling for std::unreachable if From has padding bits and To does not, a degenerate form. Despite not depending on the argument, the degenerate form of std::bit_cast does not violate the Constraints or Mandates element, leaving the bug undetected. Compilers also have no warning for the degenerate form at the time of writing.

This behavior is a footgun, and is not very useful. If users want a function that always has UB, they should be writing std::unreachable, not std::bit_cast.

Furthermore, it would be useful if bit-casting between long double and a 128-bit integer type was possible. After all, reinterpreting floating-point types and integer types is part and parcel of implementing mathematical functions like those in <cmath>. It would also be useful if this could be done portably in constant expressions. Another case where the degenerate form may arise frequently is bit-casting _BitInt (supported by Clang as an extension and proposed in [P3666R2]), considering that most _BitInt types (at least 7/8) have padding bits.

2. Design

The paper proposes the following changes:

• Make the degenerate form of std::bit_cast ill-formed by expanding the Constraints element.
• Add a new std::bit_cast_zero_padding function which maps padding bits in the source object onto zero bits in the result. Other than that, this new function has the same behavior as std::bit_cast.

2.1. Why not make std::bit_cast_zero_padding the default behavior?

It may also be possible to alter the behavior of std::bit_cast to clear padding, rather than creating a new function. However, this would be problematic because std::bit_cast can be used to convert padded types to a byte array without undefined behavior. Wiping padding bits would add more cost to existing code.

Furthermore, if users assumed std::bit_cast to wipe padding, they may inadvertently access uninitialized memory on older compiler versions, where that behavior is not implemented yet. Perfectly well-defined C++29 code with no erroneous behavior that uses std::bit_cast could be copied and pasted into older code bases, and suddenly obtain undefined behavior.

Last but not least, users may be surprised by std::bit_cast changing the value of any bits. Conceptually, it is a reinterpretation of existing bits as a new type, and it is desirable to express behavior like zeroing of padding explicitly.

2.2. Can't you clear padding bits before bit-casting?

In the discussion of this proposal prior to publication, it was suggested to clear the padding before bit-casting. That is, standardizing __builtin_clear_padding and using an idiom such as:

However, this approach does not make any sense in the C++ object model because the state of padding bits is not observable, and attempting to modify and later read their value is futile.

From a hardware perspective, long double may be stored on the x87 floating-point stack, so while it superficially has 6 padding bytes, those only exist on paper, not in hardware. Similarly, _BitInt(20) may superficially have 4 padding bits, but can be stored in a 20-bit register, where none of those bits actually exist.

The assumption that padding bits cannot be observed, may not even exist, and don't have to be preserved is crucial for compiler optimization.

Besides the hardware perspective, the approach of clearing padding bits in the object does not make any sense for constant evaluation. For instance, Clang does not store an object representation for values during constant evaluation. When bit-casting, one is generated on the fly.

2.3. Can't you make std::bit_cast produce unspecified or erroneous values?

A possible approach would be to make std::bit_cast produce unspecified bit values instead of indeterminate bit values. That is, std::bit_cast<__int128>(0.0L) would create a __int128 with 10 predictable bytes and 6 bytes with unspecified value. There are two problems with this idea:

• Since the byte values are now unspecified, UBSan (undefined behavior sanitizer) can no longer diagnose accessing/branching based on the upper 6 bytes as a bug. The bug (possibly CWE-908: Use of Uninitialized Resource) didn't go away, it just became non-conforming to diagnose it with termination.
• This approach should not work for constant evaluation because it would add non-determinism at compile time.

Overall, this design sweeps the problem under the rug with little to no benefit to the user.

It is also possible to make the result have erroneous value. However, once again, this approach could not be used to portably bit-cast long double to __int128, especially not during constant evaluation; the degenerate form of std::bit_cast would then always produce erroneous values, so it makes no sense to let it compile in the first place. This solution would only benefit the case of bit-casting to a byte array; perhaps that is worth pursuing, but the only way not to add cost to std::bit_cast (with no opt-out) would be to give the bytes an unspecified value that is considered an erroneous value. This provides minimal (if any) benefit, and could be explored in a separate paper; it is a separate issue from the one presented in this paper.

2.4. The problem of bit-casting union types

Consider the following code:

There are two possible interpretations of why this code has undefined behavior:

• The set of padding bits changes based on which union alternative is active, and U has three padding bytes when c is active.
• Even if U has no padding bits, when c is active, the following three bytes of the value representation of U are indeterminate.

The latter interpretation is more reasonable because padding bytes are intuitively a property of the type, given that object and value representations are defined as properties of types. It would be a surprising wording strategy if we considered the set of padding bits to change at run-time.

2.5. Constraints vs Mandates

The degenerate form of std::bit_cast should be diagnosed using a Mandates element (that is, static_assert). That is because the condition for the degenerate form is relatively complicated and may change in the future. Also, Constraints tempts the user to test whether bit_cast is safe using requires, but this test can have false positives. The detection of the degenerate form would only tell the user whether all possible arguments result in undefined behavior.

Conceptually, Constraints for std::bit_cast should tell the user whether bit-casting is technically feasible due to sizes matching and types being trivially copyable, whereas Mandates should catch misuses such as passing consteval-only types or types that result in the degenerate form.

3. Implementation experience

None yet.

There exists no way to query which bits or bytes of a type are padding bits, or whether a type has padding bits in the first place. Therefore, an implementation requires compiler intrinsics, both for detecting the degenerate form of std::bit_cast and for std::bit_cast_zero_padding.

4. Wording

The changes are relative to [N5014].

[version.syn]

Add a feature-test macro to [version.syn] as follows:

[bit.syn]

Change [bit.syn] as follows:

[bit.cast]

Change [bit.cast] as follows:

Append the following declaration to [bit.cast]:

5. References