Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking Issue for slice_from_ptr_range #89792

Open
2 of 5 tasks
ibraheemdev opened this issue Oct 11, 2021 · 4 comments
Open
2 of 5 tasks

Tracking Issue for slice_from_ptr_range #89792

ibraheemdev opened this issue Oct 11, 2021 · 4 comments
Labels
C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@ibraheemdev
Copy link
Member

ibraheemdev commented Oct 11, 2021

Feature gate: #![feature(slice_from_ptr_range)]

This is a tracking issue for slice::{from_ptr_range, from_mut_ptr_range}, counterparts to slice::{as_ptr_range, as_mut_ptr_range}.

Public API

// core::slice

pub unsafe fn from_ptr_range<'a, T>(range: Range<*const T>) -> &'a [T];
pub unsafe fn from_mut_ptr_range<'a, T>(range: Range<*mut T>) -> &'a mut [T];

Steps / History

Unresolved Questions

  • Will this get in the way of any future changes to the Range type(s) that we might want to make in a future version or edition?
@ibraheemdev ibraheemdev added C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. labels Oct 11, 2021
@scottmcm
Copy link
Member

scottmcm commented Mar 4, 2022

Is there anything about provenance that should be documented on these? Right now I think it always uses the provenance of the first pointer for what it puts in the slice; I'm not sure whether it would ever matter.

compiler-errors added a commit to compiler-errors/rust that referenced this issue May 29, 2022
…r=oli-obk

Make `from{,_mut}_ptr_range` const

This PR makes the following APIs `const`:
```rust
// core::slice

pub const unsafe fn from_ptr_range<'a, T>(range: Range<*const T>) -> &'a [T];
pub const unsafe fn from_mut_ptr_range<'a, T>(range: Range<*mut T>) -> &'a mut [T];
```

Tracking issue: rust-lang#89792.
Feature for `from_ptr_range` as a `const fn`: `slice_from_ptr_range_const`.
Feature for `from_mut_ptr_range` as a `const fn`: `slice_from_mut_ptr_range_const`.

r? `@oli-obk`
@WaffleLapkin
Copy link
Member

@scottmcm current implementation uses sub_ptr which has these safety conditions:

  • Both the starting and other pointer must be either in bounds or one byte past the end of the same allocated object.
  • Both pointers must be derived from a pointer to the same object. (See below for an example.)

Which I think implies that both pointers must have the same provenance.

The current documentation of from_ptr_range already mentions that it must be the same allocated object, but it doesn't mention how the pointers must be derived...

  • The range must contain N consecutive properly initialized values of type T:
    • The entire memory range of this slice must be contained within a single allocated object! Slices can never span across multiple allocated objects.

compiler-errors added a commit to compiler-errors/rust that referenced this issue May 30, 2022
…r=oli-obk

Make `from{,_mut}_ptr_range` const

This PR makes the following APIs `const`:
```rust
// core::slice

pub const unsafe fn from_ptr_range<'a, T>(range: Range<*const T>) -> &'a [T];
pub const unsafe fn from_mut_ptr_range<'a, T>(range: Range<*mut T>) -> &'a mut [T];
```

Tracking issue: rust-lang#89792.
Feature for `from_ptr_range` as a `const fn`: `slice_from_ptr_range_const`.
Feature for `from_mut_ptr_range` as a `const fn`: `slice_from_mut_ptr_range_const`.

r? `@oli-obk`
bors added a commit to rust-lang-ci/rust that referenced this issue May 31, 2022
…oli-obk

Make `from{,_mut}_ptr_range` const

This PR makes the following APIs `const`:
```rust
// core::slice

pub const unsafe fn from_ptr_range<'a, T>(range: Range<*const T>) -> &'a [T];
pub const unsafe fn from_mut_ptr_range<'a, T>(range: Range<*mut T>) -> &'a mut [T];
```

Tracking issue: rust-lang#89792.
Feature for `from_ptr_range` as a `const fn`: `slice_from_ptr_range_const`.
Feature for `from_mut_ptr_range` as a `const fn`: `slice_from_mut_ptr_range_const`.

r? `@oli-obk`
@WaffleLapkin
Copy link
Member

Can someone add #97419 to the implementation history? It made the functions const under cons_slice_from_ptr_ranget and const_slice_from_mut_ptr_range features (this also should be added in the description). It also added a reexport of these functions to alloc and std, previously these functions were only accessible via core.

@wx-csy
Copy link

wx-csy commented Oct 2, 2022

What's the behavior of these functions when T is ZST? Currently, the implementation calls pointer::offset_from, which panics if T is ZST. Maybe we have to add this to the documentation?

matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Sep 2, 2024
…lfJung

Clarify language around ptrs in slice::raw

More specifically we explicitly mention that the pointer should be non-null as a top level requirement. Nullptrs are always valid for zero sized operations, so just validity (and alignment) does not guarantee non-nullness as implied in the existing docs.

We also explicitly call out ZSTs as an additional example where perhaps unintuitively alignment and non-nullness still have to hold.

Finally we change `data` in the range functions to `start`, which seems like a typo to me.

Touches docs for rust-lang#89792

r? RalfJung
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Sep 2, 2024
…lfJung

Clarify language around ptrs in slice::raw

More specifically we explicitly mention that the pointer should be non-null as a top level requirement. Nullptrs are always valid for zero sized operations, so just validity (and alignment) does not guarantee non-nullness as implied in the existing docs.

We also explicitly call out ZSTs as an additional example where perhaps unintuitively alignment and non-nullness still have to hold.

Finally we change `data` in the range functions to `start`, which seems like a typo to me.

Touches docs for rust-lang#89792

r? RalfJung
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Sep 3, 2024
Rollup merge of rust-lang#129892 - oskgo:clarify-slice-from-raw, r=RalfJung

Clarify language around ptrs in slice::raw

More specifically we explicitly mention that the pointer should be non-null as a top level requirement. Nullptrs are always valid for zero sized operations, so just validity (and alignment) does not guarantee non-nullness as implied in the existing docs.

We also explicitly call out ZSTs as an additional example where perhaps unintuitively alignment and non-nullness still have to hold.

Finally we change `data` in the range functions to `start`, which seems like a typo to me.

Touches docs for rust-lang#89792

r? RalfJung
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

4 participants