Date: Fri, 16 Jan 2026 06:34:17 -0800
On Friday, 16 January 2026 06:03:37 Pacific Standard Time Tiago Freire via Std-
Proposals wrote:
> I think it would be a foot gun if:
>
> T1 A {};
> T2 B = std::bit_cast<T2>(A);
>
> static_assert(sizeof(T1) == sizeof(T2));
> static_assert(alignof(T1) == alignof (T2));
> assert(memcmp(&A, &B, sizeof(T1) ) !=0 );
>
> It would violate the essential contract of what `std::bit_cast` is used for.
This is exactly what happens with the 80-bit long double and uint128_t on x86.
And unlike other types of UB where some people can count on a specific
behaviour because the implementation has little freedom in what to actually
do, in this case it's *really* undefined what happens and changes very easily
with optimisations around the code.
And because of that, it's also incredibly difficult to work around it, as I
discovered trying to fix qHash(long double).
https://codereview.qt-project.org/c/qt/qtbase/+/688399
For that reason alone, I'd welcome a tool to zero out the padding bits.
Proposals wrote:
> I think it would be a foot gun if:
>
> T1 A {};
> T2 B = std::bit_cast<T2>(A);
>
> static_assert(sizeof(T1) == sizeof(T2));
> static_assert(alignof(T1) == alignof (T2));
> assert(memcmp(&A, &B, sizeof(T1) ) !=0 );
>
> It would violate the essential contract of what `std::bit_cast` is used for.
This is exactly what happens with the 80-bit long double and uint128_t on x86.
And unlike other types of UB where some people can count on a specific
behaviour because the implementation has little freedom in what to actually
do, in this case it's *really* undefined what happens and changes very easily
with optimisations around the code.
And because of that, it's also incredibly difficult to work around it, as I
discovered trying to fix qHash(long double).
https://codereview.qt-project.org/c/qt/qtbase/+/688399
For that reason alone, I'd welcome a tool to zero out the padding bits.
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Principal Engineer - Intel Data Center - Platform & Sys. Eng.
Received on 2026-01-16 14:34:25
