So reading this made me wonder about padding and niches again... I wonder if it would make sense to add a
repr attribute that basically says "for this type, instead of padding with arbitrary bytes, please pad with guaranteed zero bytes". So basically, the compiler adds padding fields of appropriate size that only have a single valid value, 0x00. That would have the downside that these bytes must be copied when the struct is copied (unlike padding), but it also means that space could be used for niche optimizations.
@eddyb probably already opened an issue for doing this 3 years ago, but at least I haven't seen it. ;)
I think this is also the direction these comments take
I have not, I don't think
That would have the downside that these bytes must be copied when the struct is copied (unlike padding)
note that this is only a thing for non-
LLVM doesn't know about padding in our
structs, it has no mechanism through which to indicate them (other then maybe first-class aggregates but we stopped using those except for pair return values)
the only change I could see being needed is
SetDiscriminant zeroing out the padding (although it would really only need to zero out the niche, optimization-wise :P)
then again such a layout would offer multiple niches if applied to
but we gave up on using multiple niches because we expected we'd never zero out padding by default and didn't think of the opt-in, so it would take more effort now
I see. So should I open a new issue for this, or is there some general niche-related issue I could add this to?
I opened an issue: https://github.com/rust-lang/rust/issues/70230
Another usecase that could benefit from guaranteed-initialised padding are eBPF programs inside the Linux kernel.
They are being statically verified, to ensure that no uninitialised memory reaches "foreign" functions.
It is currently tricky to pass Rust structs and enums to other Rust programs through these "foreign" functions, because the verifier
notices that e.g. Option<u32> contains uninitialised padding. It is sometimes possible to work around this, by manually zeroing a struct/enum,
and then setting its fields directly, without copying over the padding, but that is unergonomic.
@tilpner so... the Rust program is compiled to eBPF, and then that program is statically verified by the kernel in certain ways? that's interesting, is that analysis described in detail somewhere?
that seems to mostly be about uninitialized "registers", so compiling Rust to eBPF ends up putting enums directly in registers?