> So, to use your example with 80-bit long double on x86, where
> sizeof(long double) is 16, the behavior of memcpy must be equivalent to
> copying 16 bytes from the source to target, not 10. And this can be
> observed by a program such as this:
>
> bool test(const long double& d1)
> {
> unsigned char buf1[sizeof(long double)];
> memcpy(buf1, &d1, sizeof(long double));
> long double d2;
> memcpy(&d2, buf1, sizeof(long double));
> unsigned char buf2[sizeof(long double)];
> memcpy(buf2, &d2, sizeof(long double));
>
> return memcmp(buf1, buf2, sizeof(long double)) == 0;
> }
>
> This function must always return true, under the specification of memcpy
> and memcmp (which is also defined in C as operating on n characters).
> Whether the compiler generates code that does the actual copies and
> comparison of 16 bytes, or 10 bytes (for *both* copying and comparison)
> or none at all and just generates an equivalent of `return true` is QoI.
>

I think you're right regarding padding bits being observable, albeit only
at run-time. We have some wording that specifies values of padding bits
(e.g. zero-initialization says padding bits are zero), and so there are
some cases where padding bits are not indeterminate. I was operating under
the assumption that padding bits are indeterminate in all cases, but
they're not.

However, there is nothing that guarantees you that your test function is
well-defined. If d1 has dynamic storage duration or is marked
[[indeterminate]], padding bytes have indeterminate value, so you're just
reading uninitialized memory, and the function has undefined behavior. In
most other cases (e.g. local variables), d1 has padding bits with erroneous
value. This is a huge footgun, and encouraging users to modify and access
padding is exactly the wrong design direction.

Even in the few cases where padding bits have specified value, that value
is very easily lost through lvalue-to-rvalue conversion or any kind of
arithmetic operation.


> The proposed clear_padding utility would be defined as "sets all bits in
> the object representation that do not participate in value
> representation to zero" or something along these lines. This is a
> perfectly reasonable definition that is in line with the existing object
> model.
>

I have yet to hear any attempt at an argument for why we would want a
clear_padding utility rather than a bit_cast_zero_padding utility. As I've
said, padding bits are very easily lost. It also requires expert-level
knowledge to understand when padding bits have some specified value and
when they revert back to indeterminate or erroneous value. A clear_padding
utility also would not work for constant evaluation.

That being said, I'm not strongly opposed to making bit_cast preserve the
values of padding bits at run-time. However, that doesn't really solve the
problem that I set out to fix here. Those padding bits are almost certainly
going to be erroneous or indeterminate if the user doesn't use clear_padding,
and clear_padding doesn't really work during constant evaluation without
substantial changes to implementations.

The clear_padding + bit_cast idiom encourages the user to write the wrong
kind of code. If you forget clear_padding, you may get undefined behavior,
and what is currently a degenerate form of bit_cast that we could reject at
compile time (because it always produces UB) becomes undiagnosable; the
user could have run bit_cast expecting the padding bits to be copied, and
the compiler has no way of knowing whether that's the intent. Very sharp
edge!