śr., 21 sty 2026 o 19:03 Jan Schultke via Std-Proposals
<std-proposals_at_[hidden]> napisał(a):
>
>
>
> On Wed, 21 Jan 2026 at 19:00, Thiago Macieira <thiago_at_[hidden]> wrote:
>>
>> On Wednesday, 21 January 2026 09:41:12 Pacific Standard Time Jan Schultke
>> wrote:
>> > > > Because the result of std::bit_cast has unspecified padding bits, so x =
>> > >
>> > > Unless we change std::bit_cast, which is what I am proposing.
>> >
>> > It would be an ABI break if you changed that, and compilers would
>> > essentially have to invent new ABI for all kinds of platforms to make this
>> > work, so the std::bit_cast that you're proposing is practically
>> > unimplementable.
>>
>> Why are you saying that? How is the behaviour of std::bit_cast ABI in the first
>> place?
>
>
> Because it's a function and returns by value, so it's limited by the calling conventions for the platform, and whether those preserve padding (they usually don't). Ergo, at least on a debug build, you're not getting any padding bits from a function call to std::bit_cast.

And how is the problem exactly? If I follow this discussion, the
problem is that padded type when cast to not padded type can have
"poison" bits.
But in other ways around, do not matter as bits simply are not
observable as they become part of padding.
This only is a problem if we try to do a round trip like `x ==
std::bit_cast<X>(std::bit_cast<Y>(x))`.

> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals