On January 18, 2026 2:24:40 AM Thiago Macieira via Std-Proposals
<std-proposals_at_[hidden]> wrote:

> On Saturday, 17 January 2026 12:03:13 Pacific Standard Time David Brown wrote:
>> But the padding /can/ be observed - and not just via bit_cast. Every
>> object in C++ can be viewed as an array of unsigned char (or std::byte)
>> - by memcpy, or by casting a pointer to the object to a pointer to
>> unsigned char.
>>
>> And there are plenty of situations where you would want the padding to
>> be seen as zeros, or at least to be consistent. Taking a hash of some
>> kind is the obvious case - whether it be for use in a hash-map
>> structure, for integrity checking (CRC, md5sum), or for secure hashing.
>> You might also want it to be zeroed out before passing the object
>> outside the program - storing it in a file, or transmitting it on a
>> network. Again, it is often helpful for data to be consistent, and more
>> paranoid people might want to avoid any risk of leakage of unintended
>> data. Often it is most efficient and convenient to access the data here
>> using std::byte or unsigned char pointers - and that means the padding
>> is visible.
>
> Most of which require a bit_cast to a byte array in the first place.
>
> The only case that doesn't is using write()/send(), which is equivalent to
> memcpy() to permanent storage. That isn't known to be a problem these days
> because it's a known quantity and most of the issues that stem from it are
> known. Serialisation protocols are careful to store reproducible data without
> padding bits in the first place, instead of zeroing them - padding in storage
> is inefficient.

IO is not the only use case. The object may be put in process-shared
memory, for example, and using the simplest possible serialization (i.e.
memcpy) for performance reasons. Clearing padding of garbage may still be
desired to avoid leaking data.

> That said, if there is a need, std::clear_padding() could be implemented by:
>
> using Tmp = std::array<unsigned char, sizeof(T)>;
> Tmp tmp = std::bit_cast<Tmp>(src); // or std::bit_cast_clear_padding
> src = std::bit_cast<T>(tmp);

This wouldn't work, as the second bit_cast doesn't guarantee zero padding
bits in the result.

Besides, this is backwards. clear_padding is supposed to be a building
block for higher level operations, not a construct on top of them. I think
coupling bit_cast with clear_padding is a mistake. Those are two separate
operations, and should exist as such.