You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
GenericArray should implement Index{,Mut} as well as a way to get a pointer to a field #75
A partially-uninitialized GenericArray at almost any time is asking for undefined behavior. Although it would be fine for Copy types with no Drop, anything else is a bad idea.
However, there are intentionally undocumented but publicly exported structures in generic-array for safely constructing GenericArrays one element at a time.
Likewise, there is also ArrayConsumer for the inverse.
The primary difference is their Drop behavior.
If you must use uninitialized memory with GenericArray, use the above helpers instead. Otherwise, fill them with a default value like zero or use GenericArray::generate/GenericArray::default
As for Index/IndexMut, I can do that. yourarray[0] already works thanks to Deref-ing into a slice, but I can see how implementing the trait itself would be necessary for generics.
I'm pretty deep into unsafe stuff, and so long as GenericArray<T, N> behaves like [T; N], I think I'm handling initializing, dropping etc. correctly :) However, as soon as I Deref into a slice I'm getting into the “officially UB but actually works” land, as it's creating a reference to uninitialized data… which I think is an error made here:
Having Index{,Mut} would hopefully allow not going through a slice and thus safely indexing into a partially-uninitialized GenericArray (assuming it has indeed been initialized at the accessed index).
And the “way to get a pointer to a field” from the title would allow for a way to initialize an element without insta-UB, as getting a reference to a not-yet-initialized item is officially UB.
Dereferencing into a slice is totally fine so long as you don't read uninitialized data or overwrite initialized data. A slice doesn't own the memory, so it can't drop it.
The entire reason ArrayBuilder and ArrayConsumer exist is to handle what happens if something panics during initialization/deconstruction. The Drop implementation on each will drop any created or remaining elements, and leave uninitialized elements as they are. The builder and consumer wrap the array in ManuallyDrop so undefined behavior cannot be triggered.
Slices are a magical construct in Rust, and allow for incredible optimizations when used. In fact, ArrayBuider and ArrayConsumer are typically entirely optimized away for arrays of primitive types, but provide a safety net for arrays of types with Drop implementations.
Something you cannot do is random-access initialize/deinitialize elements, which is what it sounds like you want. If the types you want are Copy primitives without Drop, I'd highly recommend using GenericArray::generate/GenericArray::default first and then accessing them in whatever order you please.
Dereferencing into a slice is totally fine so long as you don't read uninitialized data or overwrite initialized data. A slice doesn't own the memory, so it can't drop it.
It is not. The fact the slice won't drop the memory does not make it not-UB to have a slice pointing to undefined memory. rust-lang/rfcs#1892 (comment) explicitly reminds it. And rust-lang/rfcs#1892 (comment) is a nice example of why it's hard to do it any other way, for optimization purposes.
Now, we totally agree that in practice it should work most of the time, but it is not guaranteed by current Rust.
If the types you want are Copy primitives without Drop
Well, my types are not Copy and are Drop, so I've got quite a bit of code that's (trying to) do this correctly :)
My main issue has been that for this I needed to do .as_slice(), even if it was just to access a pointer to the element and ptr::write or ptr::drop_in_place it. Which, while in practice it works, is UB, as I'm having a &[T] for half a tick (ie. just before it's converted to a pointer) in which some items are potentially not actually well-formed Ts.
Activity
novacrazy commentedon Apr 17, 2019
A partially-uninitialized
GenericArrayat almost any time is asking for undefined behavior. Although it would be fine forCopytypes with noDrop, anything else is a bad idea.However, there are intentionally undocumented but publicly exported structures in
generic-arrayfor safely constructingGenericArrays one element at a time.See here for
ArrayBuilderand and example of how it's used.Likewise, there is also
ArrayConsumerfor the inverse.The primary difference is their
Dropbehavior.If you must use uninitialized memory with
GenericArray, use the above helpers instead. Otherwise, fill them with a default value like zero or useGenericArray::generate/GenericArray::defaultAs for
Index/IndexMut, I can do that.yourarray[0]already works thanks toDeref-ing into a slice, but I can see how implementing the trait itself would be necessary for generics.Ekleog commentedon Apr 17, 2019
I'm pretty deep into unsafe stuff, and so long as
GenericArray<T, N>behaves like[T; N], I think I'm handling initializing, dropping etc. correctly :) However, as soon as IDerefinto a slice I'm getting into the “officially UB but actually works” land, as it's creating a reference to uninitialized data… which I think is an error made here:generic-array/src/lib.rs
Line 195 in 459abe4
Having
Index{,Mut}would hopefully allow not going through a slice and thus safely indexing into a partially-uninitializedGenericArray(assuming it has indeed been initialized at the accessed index).And the “way to get a pointer to a field” from the title would allow for a way to initialize an element without insta-UB, as getting a reference to a not-yet-initialized item is officially UB.
novacrazy commentedon Apr 17, 2019
Dereferencing into a slice is totally fine so long as you don't read uninitialized data or overwrite initialized data. A slice doesn't own the memory, so it can't drop it.
The entire reason
ArrayBuilderandArrayConsumerexist is to handle what happens if something panics during initialization/deconstruction. TheDropimplementation on each will drop any created or remaining elements, and leave uninitialized elements as they are. The builder and consumer wrap the array inManuallyDropso undefined behavior cannot be triggered.Slices are a magical construct in Rust, and allow for incredible optimizations when used. In fact,
ArrayBuiderandArrayConsumerare typically entirely optimized away for arrays of primitive types, but provide a safety net for arrays of types withDropimplementations.Something you cannot do is random-access initialize/deinitialize elements, which is what it sounds like you want. If the types you want are
Copyprimitives withoutDrop, I'd highly recommend usingGenericArray::generate/GenericArray::defaultfirst and then accessing them in whatever order you please.Ekleog commentedon Apr 17, 2019
It is not. The fact the slice won't drop the memory does not make it not-UB to have a slice pointing to undefined memory. rust-lang/rfcs#1892 (comment) explicitly reminds it. And rust-lang/rfcs#1892 (comment) is a nice example of why it's hard to do it any other way, for optimization purposes.
Now, we totally agree that in practice it should work most of the time, but it is not guaranteed by current Rust.
Well, my types are not
Copyand areDrop, so I've got quite a bit of code that's (trying to) do this correctly :)My main issue has been that for this I needed to do
.as_slice(), even if it was just to access a pointer to the element andptr::writeorptr::drop_in_placeit. Which, while in practice it works, is UB, as I'm having a&[T]for half a tick (ie. just before it's converted to a pointer) in which some items are potentially not actually well-formedTs.korken89 commentedon Oct 28, 2019
Hi, I'd like to revive this issue.
We need something similar for use in creating generic DMA buffers in Rust Embedded.