Date: Sat, 17 Jan 2026 15:24:29 -0800
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.
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);
We can hope the compilers see this passage through a temporary and simply
clear the bits.
> Converting a type into a similar type but with the padding bits and
> bytes visible and zeroed out is, I think, an interesting idea - but I
> fear it would be very difficult to specify accurately. This new type
> could pick up the data fields of the original type, but what about its
> methods, static data, other functions with overloads, its ancestors and
> descendants, and anything else relevant to the type? I think all you
> could reasonably do is convert to an array of unsigned char (or
> std::byte) of appropriate size.
That's entirely out-of-scope and the boat has already sailed on that, once
std::bit_cast was created.
> 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.
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);
We can hope the compilers see this passage through a temporary and simply
clear the bits.
> Converting a type into a similar type but with the padding bits and
> bytes visible and zeroed out is, I think, an interesting idea - but I
> fear it would be very difficult to specify accurately. This new type
> could pick up the data fields of the original type, but what about its
> methods, static data, other functions with overloads, its ancestors and
> descendants, and anything else relevant to the type? I think all you
> could reasonably do is convert to an array of unsigned char (or
> std::byte) of appropriate size.
That's entirely out-of-scope and the boat has already sailed on that, once
std::bit_cast was created.
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Principal Engineer - Intel Data Center - Platform & Sys. Eng.
Received on 2026-01-17 23:24:36
