So you say clearing the padding would not necessarily have to survive passing function boundaries? IMHO that construct is quite shaky (for human reasoning and teaching), if a type keeps the padding for the near future after clear_padding, but does not keep it intact for assignments, calling functions, returning from functions.   -----Ursprüngliche Nachricht----- Von:Andrey Semashev via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Fr 23.01.2026 12:57 Betreff:Re: [std-proposals] Fixing std::bit_cast padding bit issues An:std-proposals_at_[hidden]; CC:Andrey Semashev <andrey.semashev_at_[hidden]>; On 23 Jan 2026 14:20, Sebastian Wittmeier via Std-Proposals wrote: > Would also (in your view of the updated abstract machine in regards to > padding) a > > std::set_padding(f); // set all padding bits to 1 > > work in principle? > > So f would hold and keep the actual padding bits? Or would it only work > with zeroing the bits? In principle, set_padding could exist and work similarly to clear_padding. But I don't see much use for set_padding, so I'm not proposing it. Tracking only the "cleared"/"not cleared" flag for padding may be cheaper in terms of the resources the compiler consumes during compilation, compared to "cleared"/"set"/"unknown". But I suspect the compiler vendors will want to leverage the bit pattern tracking machinery they already have in place, and in this case the specific bit patterns in padding become almost irrelevant. At least, all-zeroes and all-ones are very wide spread bit patterns, so it is reasonable to expect compilers to recognize and leverage them very efficiently. I'm not a compiler developer though, so I may be wrong about this. > If only clear_padding is required, the compiler could clear the padding > at any time. And sometimes it is required to clear those, but in doubt > it could just clear them, too. Yes, that would be allowed, but since this would be not free performance-wise, I don't think compilers would do that. We are proposing the clear_padding function to tell the compiler when the padding is important, precisely to let it continue to largely ignore it in other contexts. > If both instructions would/should work, it has to keep the current > padding bits as actual information within the type representation and > operations. No. Again, the padding contents matter only when they are consumed by a following operation, such as memcpy or bit_cast. Whether you set the padding bits to 0 or 1 is not important in terms of language rules or data dependency tracking. When operations are defined only in terms of value representation (e.g. assignments, reads and practically any core language operations), the compiler may still ignore padding as it does today. And yes, it may not preserve a previously cleared/set padding as part of those operations. -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals