Date: Wed, 21 Jan 2026 21:10:28 +0000
On Wednesday, January 21st, 2026 at 8:03 PM, Jan Schultke via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
>
> 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.
I wonder how it plays with guaranteed RVO. If the return value conceptually initializes the result directly, shouldn't that technically include padding? (I guess that's mostly academic, since compilers don't do it in practice)
>
>
> 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.
I wonder how it plays with guaranteed RVO. If the return value conceptually initializes the result directly, shouldn't that technically include padding? (I guess that's mostly academic, since compilers don't do it in practice)
Received on 2026-01-21 21:10:37
