On Sunday, 18 January 2026 03:07:40 Pacific Standard Time David Brown wrote:
> On 18/01/2026 00:24, Thiago Macieira wrote:
> > On Saturday, 17 January 2026 12:03:13 Pacific Standard Time David Brown
wrote:
> >> 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.
>
> Do they? People have been doing this sort of thing with memcpy and
> unsigned char pointers from /long/ before C++20 bit_cast<>, both in C
> and C++ (AFAIK C++ defers to the C standard for memcpy). bit_cast<>
> might be a more modern way to deal with this kind of thing, and it will
> likely be a better route towards consistent compile-time and run-time
> behaviour, but accessing representations via unsigned char pointer has
> always been fundamental to low-level work in C and C++. And the unknown
> contents of padding has been a PITA all that time. Rightly or wrongly,
> people treat coping the padding via character pointers as getting
> unspecified data, not as leading to undefined behaviour.

What people have been doing is not important, because they are not using any
of the solutions we're talking about yet. We are discussion what they need to
use now.

I also argue there's no such code today because there is no way to clear
padding. Therefore, no one is knowingly using hashes and checksum functions
over the storage of an object that contains padding.

So we are talking about a new use-case that we can enable. And therefore, by
construction, both solutions are acceptable. Which would be most convenient?

There's value in std::clear_padding for this use-case: it wouldn't require the
callee to create a new buffer of the object before reading the memory
representation in order to calculate whatever they need to. Since those are
padding bits, the caller can afford to clear them in their working object,
since by definition they aren't used to store any value.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Principal Engineer - Intel Data Center - Platform & Sys. Eng.