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
Tracking issue for ptr::slice_from_raw_parts[_mut] #36925
In stable Rust, the only way to get a *const [T] with an arbitrary length is through slice::from_raw_parts. Unfortunately, that function returns a &[T], which makes it very dubious to use with arbitrary raw pointers.
Why would you want one, but also, this seems like it depends on (yet to be decided?) details of the memory model. Is the fleeting moment where a reference exists in unsafe { slice::from_raw_parts(0xDEADBEEF, 42) as *const [T] } enough to invoke UB if the pointer is invalid?
Is there anything holding slice_from_raw_parts[_mut] from stabilizing? If not, I'd like to propose stabilization of these functions, as they are rather simple in concept and allow avoiding manifesting references during (slice) pointer manipulation.
If I'm reading the various issue threads correctly, the validity invariant of pointer metadata is at max that of the metadata type. For slice pointers, the metadata is typed at usize.
Context: I happen to currently be writing a library that cannot use the reference-based functions, because though the pointers are known to be non-null (and valid), it is not (and cannot be, with the current abstraction) known whether the pointer has unique or shared provenance (thus should use slice::from_raw_parts or slice::from_raw_parts_mut to be sound). (Specifically, I'm now adding the bits required to handle erasing slice types. I can bifurcate my unerase function into unerase_const and unerase_mut, but so far, it works fine with one unerase operating over ptr::NonNull, and it'd be sad to have the _const/_mut split hanging around even after these functions stabilize (assuming they can)).
changed the title [-]There is no stable way to get an `*const [T]` from a ptr and a len[/-][+]Tracking issue for `ptr::slice_from_raw_parts[_mut]`[/+]on Jan 15, 2020
Activity
Thiez commentedon Oct 3, 2016
Given that
Indexisn't defined for*const [T], what would be the value of being able to create*const [T]?durka commentedon Oct 3, 2016
Why would you want one, but also, this seems like it depends on (yet to be decided?) details of the memory model. Is the fleeting moment where a reference exists in
unsafe { slice::from_raw_parts(0xDEADBEEF, 42) as *const [T] }enough to invoke UB if the pointer is invalid?arielb1 commentedon Oct 3, 2016
@durka
If the reference is
null, then this is insta-UB for sure.Rollup merge of rust-lang#60667 - oli-obk:raw_from_raw_parts, r=sfackler
Rollup merge of rust-lang#60667 - oli-obk:raw_from_raw_parts, r=sfackler
CAD97 commentedon Jan 13, 2020
Is there anything holding
slice_from_raw_parts[_mut] from stabilizing? If not, I'd like to propose stabilization of these functions, as they are rather simple in concept and allow avoiding manifesting references during (slice) pointer manipulation.cc @RalfJung #63880 #63851 @rust-lang/wg-unsafe-code-guidelines
If I'm reading the various issue threads correctly, the validity invariant of pointer metadata is at max that of the metadata type. For slice pointers, the metadata is typed at
usize.Context: I happen to currently be writing a library that cannot use the reference-based functions, because though the pointers are known to be non-null (and valid), it is not (and cannot be, with the current abstraction) known whether the pointer has unique or shared provenance (thus should use
slice::from_raw_partsorslice::from_raw_parts_mutto be sound). (Specifically, I'm now adding the bits required to handle erasing slice types. I can bifurcate myunerasefunction intounerase_constandunerase_mut, but so far, it works fine with oneuneraseoperating overptr::NonNull, and it'd be sad to have the_const/_mutsplit hanging around even after these functions stabilize (assuming they can)).nikomatsakis commentedon Jan 13, 2020
I don't recall any reason that
slice_from_raw_partscannot be stabilized.SimonSapin commentedon Jan 15, 2020
The implementation PR #60667 used this feature requested as a tracking issue, but this wasn’t labelled properly. Doing so now.
[-]There is no stable way to get an `*const [T]` from a ptr and a len[/-][+]Tracking issue for `ptr::slice_from_raw_parts[_mut]`[/+]SimonSapin commentedon Jan 15, 2020
By the way, rust-lang/rfcs#2580 would also cover this :)
Auto merge of #68234 - CAD97:slice-from-raw-parts, r=KodrAus