Tracking Issue for feature(ptr_to_from_bits)

[scottmcm]

Feature gate: #![feature(ptr_to_from_bits)]

This is a tracking issue for <*const T>::from_bits, <*mut T>::from_bits, <*const T>::to_bits, and <*mut T>::to_bits.

These, like the stable <*const T>::cast and <*mut T>::cast, is proposed as a method for one of the many specific things that as can do to help increase readability of which of those things is happening, as well as to be able to give better compilation errors (or lints) for suspicious code patterns that aren't necessarily wrong. (For example, p as u32 is legal but suspicious, as it's possible it was meant to be *p as u32. By having the method, p.to_bits() as u32 is unambiguous.)

See the conversation in https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Adding.20methods.20as.20more.20specific.20versions.20of.20.60as.60/near/238391074

Public API

impl<T> *const T {
    pub fn to_bits(self) -> usize where T: Sized;
    pub fn from_bits(bits: usize) -> Self where T: Sized;
}
impl<T> *mut T {
    pub fn to_bits(self) -> usize where T: Sized;
    pub fn from_bits(bits: usize) -> Self where T: Sized;
}

Steps / History

• Implementation: Add <*{const|mut} T>::{to|from}_bits #91127
• Final comment period (FCP)
• Stabilization PR

Unresolved Questions

• None yet.

[leonardo-m]

(For example, p as u32 is legal but suspicious, as it's possible it was meant to be *p as u32. By having the method, p.to_bits() as u32 is unambiguous.)

I'm not a fan of "as" casts in general :-]

[workingjubilee]

I do not believe these methods are the correct ones. In particular, I believe that stabilizing these methods would force Rust further down an incorrect evolutionary path regarding its story of pointers in general.

[jendrikw]

Could we consider adding this to fn pointers?

[fbstj]

is this related to #95241 ?

[Gankra]

ptr_to_from_bits is inherently contradictory to the goals of the strict_provenance (#95228) experiment, yes. In my initial WIP PR I actually marked them as deprecated just to see what was using them.

The problems are that they:

• Imply ptr-int-ptr roundtrips
• Specify that ptr==usize (intptr_t)

Strict provenance is experimenting with whether we can specify

• ptr-int-ptr doesn't actually work
• ptr>=usize (size_t)

Both of these are very desirable for more properly targetting CHERI. The APIs don't need to be deprecated but stabilization should maybe be held off on while we're experimenting in this space.

[scottmcm]

@fbstj No, this came from a much less interesting place of wanting to be able to better lint typos like isize::max as usize, which very much doesn't do what you want 🙃

With https://doc.rust-lang.org/nightly/std/primitive.pointer.html#method.addr now available, I think this feature should just be deprecated. To be nice, though, we shouldn't remove this for another 5 weeks or so, to give unstable users an easier transition.

EDIT: I opened #95583 to do that.

[jmillikin]

The 1 year anniversary of deprecating the ptr_to_from_bits functions is approaching -- would it be OK to tidy up and delete them now?