Is there any way to get Box<T> where T is not initialized without storing T on the stack first?
#Uninit Box
proud pumice
finite pelican
On nightly, there's https://doc.rust-lang.org/std/boxed/struct.Box.html#method.new_uninit
On stable, you have to:
- make sure the type isn't a ZST
- call https://doc.rust-lang.org/std/alloc/fn.alloc.html
- call https://doc.rust-lang.org/std/boxed/struct.Box.html#method.from_raw
dusky acorn
there's also things like https://docs.rs/bytemuck/latest/bytemuck/allocation/fn.zeroed_box.html which you may be able to use depending on what T is
finite pelican
Huh. Seems like the unstable method is likely to be stable in the version after next (1.82). It just finished FCP.
proud pumice
pub unsafe fn uninit_box<T>() -> Box<T> {
let layout = Layout::new::<T>();
let ptr = alloc(layout) as *mut T;
if ptr.is_null() {
handle_alloc_error(layout);
}
Box::from_raw(ptr)
}```
Aside from T being uninitialized, is there any other safety concern? (asking because I'm not sure if this deallocates)that's a pretty huge "aside"
proud pumice
I know, that's why I marked the fn as unsafe, but I meant if there are other issues I'm oblivious to
dusky acorn
it being uninitialized is a much bigger problem than you seem to think
you are not handling zero sized types correctly
it's also insta ub if you call it for types like u8 for example
anything that needs initializing
the ub happens inside the function, not in whatever the caller does with it next
that is because it's UB to have uninitialized values, not just when you use them
proud pumice
thanks, I might also give a deeper look to the unsafe docs
finite pelican
thanks, I might also give a deeper look to the unsafe docs
use std::alloc::{alloc, Layout};
use std::mem::MaybeUninit;
use std::ptr::NonNull;
pub fn uninit_box<T>() -> Box<MaybeUninit<T>> {
unsafe {
Box::from_raw(if size_of::<T>() == 0 {
NonNull::dangling().as_ptr()
} else {
let layout = Layout::new::<T>();
let ptr = alloc(layout).cast::<MaybeUninit<T>>();
if ptr.is_null() {
panic!("allocation failed");
}
ptr
})
}
}
lyric isle
you can also just.. Box::new(MaybeUninit::uninit())
lyric isle
it's also insta ub if you call it for types like u8 for example
I don't think it's insta ub? you don't have a uninitialized value. you have a pointer to uninitialized memory, which is fine.
it will of course still blow up the second you are using the box, but the creation itself is fine
rose finch
you can also just.. `Box::new(MaybeUninit::uninit())`
He wanted to not store it on the stack first
?eval Box::new(std::mem::MaybeUninit::<[i128; 10000000]>::uninit())
velvet lionBOT
thread 'main' has overflowed its stack
fatal runtime error: stack overflow```
dense current
I don't think it's insta ub? you don't have a uninitialized *value*. you have a ...
I think it's instant UB, just like MaybeUninit::<u8>::uninit().assume_init() is insta UB
because the compiler is allowed to read the value at any point (even if it probably won't)
dusky acorn
its kinda undecided what happens if there's indirection
latent robin
?eval `Box::new(std::mem::MaybeUninit::<[i128; 10000000]>::uninit())`
Maybe the implementation of Vec::with_capacity will be useful for this case.
?eval ```rust
Vec::<i128>::with_capacity(10000000)
[]```for context: they are basically implementing a simplified Vec as an exercise in unsafe code
so using Vec is correct, but against the spirit ;)
latent robin
I don't mean using Vec, but seeing how with_capacity allocates (it seems to use the allocator directly) without exploding the stack might be useful.