Tracking Issue for const offset_from (const_ptr_offset_from)

[RalfJung]

The feature gate for the issue is #![feature(const_ptr_offset_from)].

This tracks constness of the following function(s):

impl<T> *const T {
  const unsafe fn offset_from(self, origin: *const T) -> isize
}

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

Steps

• Implementation
• Stabilization report: Tracking Issue for const offset_from (const_ptr_offset_from) #92980 (comment)
• Stabilization PR (see instructions on rustc-dev-guide)

Unresolved Questions

• Should we allow calling this function in case both pointers point to the same allocation (in terms of their provenance) but are not both in-bounds? Cc CTFE: there is no way to compute the difference between two ptrs in the same allocation if they might be out-of-bounds #92512
  → this can be resolved post-stabilization since it is backwards compatible

Implementation history

• see Tracking issue for ptr::offset_from (feature: ptr_offset_from) #41079
• CTFE/Miri: detect out-of-bounds pointers in offset_from #94827

[RalfJung]

Cc @rust-lang/wg-const-eval

[kupiakos]

I'd like to see if we can work out the kinks and stabilize this sooner rather than later. Since addr_of! is stable, this being stabilized would enable us to do something quite powerful: stable const-time offset_of. See here for an example. With that, we can get stable const-time calculation of padding byte locations, something that could be very helpful for the zerocopy library and related firmware code.

[RalfJung]

See here for an example.

Note that that macro has some subtle flaws, see https://github.com/Gilnaa/memoffset for a bullet-proof (and also nightly-const-compatible) version. In particular it protects against .field triggering deref coercions, which make your version of the macro unsound.

[RalfJung]

But regarding this tracking issue, I think it would be good to fix rust-lang/miri#1950 before stabilizing, to ensure we actually check the UB for this function properly. (Miri and CTFE share that implementation.) Other than that, I am not aware of any blockers. I think we should do the change suggested in #92512, but that can happen post-stabilization.

[kupiakos]

Good call on the Deref soundness, rest assured I'm not copying playground code into production 😃

I'll see if I can spend some time looking at the change or issue.

In the meantime, I think I may have found an alternative way to calculate offset_of! in stable CTFE that doesn't depend on pointer arithmetic, it's just more expensive at compile time (obviously this contains the same Deref flaw currently)

[RalfJung]

Stabilization report

I would like to propose this feature for stabilization: it allows const-code to call

impl<T> *const T {
  const unsafe fn offset_from(self, origin: *const T) -> isize
}

Click here for method docs

offset_from has been stabilized for runtime code more than 1.5 years ago (see #41079). Its CTFE implementation is shared with Miri and has been working fine for a long time; #94827 works out the last kink (but even that is optional since we do not guarantee to detect all UB). This is the last feature that is missing to be able to implement offset_of! in a const-compatible way, which has been a long time coming. :)

This cycle we are also on track to const-stabilize a whole lot of other pointer offset functions (#71499), so this fits quite well.

The tests for this feature are at

• https://github.com/rust-lang/rust/blob/335ffbfa547df94ac236f5c56130cecf99c8d82b/src/test/ui/consts/offset_from_ub.rs
• https://github.com/rust-lang/rust/blob/335ffbfa547df94ac236f5c56130cecf99c8d82b/src/test/ui/consts/offset_from.rs

In the future I would like to relax the UB restrictions of this function (#92512), but that should be backwards compatible so it does not have to block stabilization.

@rust-lang/lang can I ask for the FCP process to be initiated?

[RalfJung]

Or is this for @rust-lang/libs-api ? It is const-exposing an intrinsic (that could not be implemented in pure Rust), so... possibly both.

[scottmcm]

Both teams sounds reasonable, yeah.

Teams, do we want to allow offset-between-pointers calculations in const?

Stabilization report from Ralf: #92980 (comment)

@rfcbot fcp merge

One correction to the report: it's T: Sized only, due to a where clause:

rust/library/core/src/ptr/const_ptr.rs

Lines 441 to 452 in 335ffbf

	#[stable(feature = "ptr_offset_from", since = "1.47.0")]
	#[rustc_const_unstable(feature = "const_ptr_offset_from", issue = "92980")]
	#[inline]
	pub const unsafe fn offset_from(self, origin: *const T) -> isize
	where
	T: Sized,
	{
	let pointee_size = mem::size_of::<T>();
	assert!(0 < pointee_size && pointee_size <= isize::MAX as usize);
	// SAFETY: the caller must uphold the safety contract for `ptr_offset_from`.
	unsafe { intrinsics::ptr_offset_from(self, origin) }
	}

[rfcbot]

Team member @scottmcm has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @cramertj
• @dtolnay
• @joshtriplett
• @m-ou-se
• @nikomatsakis
• @pnkfelix
• @scottmcm
• @yaahc

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.