@RalfJ so the problem is that
MaybeUninit<T> does not have the same
T, which has performance implications (e.g. if
repr(simd)) and also means that one cannot use
MaybeUninit<T> in C FFI where a
T is expected.
MaybeUninit<T> is an union with two variants with potentially two different
reprs, I don't think that
repr(transparent) makes sense here :/
Maybe a way to select from which variant the union gets its
What's been done in #55834 is to restrict any ABI fiddling to unions with only one non-(size=0, align=1) field, analogously to how transparent structs can have only one such field
But I am puzzled by the mention of FFI. Passing or receiving uninitalized data is UB in C, isn't it?
oh no i misrepresented #55834 but anyway it doesn't try to handle arbitrary unions with arbitrary fields and that's the key
right but its the same restrictions as for repr(transparent) structs as you said
so it seems the same attribute would make a lot of sense for unions as well
also this is just about deciding which ABI to use to pass these guys around; which further restrictions there are in terms of the values you have in there depends on the language on the other side of the FFI interface
and uninitialized data in C is a complicated topic...
It's quite complex, yes, but at the end what matters to me is: are there any reasonable Rust programs that benefit from passing MaybeUninit by value across the FFI boundary? Because that is all repr(transparent) is about, you can get any memory layout compatibility you want with repr(C) or (preferably) by Rust deciding to not try to be too clever by half about union memory layout
for structs, newtypes are a pretty good argument. but "new-unions" would be a new pattern to me and I dont think I'd like it^^
@rkruppe I guess the slightly higher-level question is whether there is a good reason for passing what is known to be uninitialized data by value across an FFI boundary. With very few (if any) exceptions, uninitialized data should be inside a
well let's hear it from @gnzlbg since they brough up ffi
so in stdsimd we use C FFI to call LLVM intrinsics directly...
I don't remember if there was a way to obtain
undef by doing so, but that's what I had in mind
or in other words, just because it is called C FFI does not mean that we are actually doing FFI with C, but for something that exposes the C ABI
i don't know what the different C ABIs say about uninitialized memory, but probably they just say nothing
it seems reasonable to expect these ABIs to require behaving as if the code being called was C, which would mean that callers can assume that the values being passed cannot be uninitialized, don't know
so for stdsimd we don't really need any feature, it can just rely on rustc codegen details (as it already does, heavily, in many other places)
non-C code using "the C ABI" is interesting, for example one could imagine a Rust library exposing a C ABI, but OTOH I still struggle to imagine needing to pass uninitialized data in those cases
yeah, me too, i only had in mind using this when interfacing with LLVM
where'd you need it when interfacing with LLVM?
All these intrinsics return vectors with "undefined" elements.
Some of these intrinsics are already in stable, and they should be returning
MaybeUninit<__m128> instead of just
Once we can use
MaybeUninit in stable APIs, we should try to fix those in a backwards incompatible way (doing a crater run, etc.)
@gnzlbg but to construct an
MaybeUninit<__m128> you don't need an intrinsic
indeed, I don't know why I have in mind that we were calling into LLVM intrinsics for any of those
@RalfJ can we use
MaybeUninit in stable APIs already ?
that is, is
MaybeUninit already stable ?
Also, the intrinsics "construct a vector with uninitialized elements".
Checking the source code for some, they are built by using
__m128(uninitialized(), uninitialized(), ...)
and not just
uninitialized::<__m128>() for some reason
that is, is
MaybeUninitalready stable ?
we should first get https://github.com/rust-lang/rust/pull/54668 landed
and there are some API discussions in the tracking issue