Tracking Issue for `pointer::mask`

[WaffleLapkin]

Feature gate: #![feature(ptr_mask)]

This is a tracking issue for <*const T>::mask and <*mut T>::mask methods that allow masking pointers.

Public API

impl<T: ?Sized> *const T {
    pub fn mask(self, mask: usize) -> *const T;
}

impl<T: ?Sized> *mut T {
    pub fn mask(self, mask: usize) -> *mut T;
}

Steps / History

• Implementation: Add pointer masking convenience functions #96946
• Final comment period (FCP)
• Stabilization PR

Unresolved Questions

• None yet.

[hsanzg]

Are there plans to make the ptr_mask (and therefore ptr::mask) usable from const contexts?

This currently depends on making ptr::map_addr and ptr::with_addr const, which would need to be discussed in the context of the strict provenance project.

[RalfJung]

These functions cannot in general be made const-compatible, since their behavior depends on the exact bits of a pointer value which are not known at compile-time. with_addr will never be const. (More specifically, subtracting two pointers will never be possible at const-time, and with_addr depends on that ability.)

Certain tricks could be played for the specific case where the original allocation was sufficiently aligned to make the lowest bits of the pointers statically predictable. That would need new specialized intrinsics though, it cannot be implemented via with_addr.

[RalfJung]

Don't we also need an operation that corresponds to ptr.map_addr(|a| a | mask) to make this sufficient for tagged pointers? But somehow LLVM seems to only support &, not |, on pointers?

(Maybe LLVM should just support what we call addr and with_addr, then it wouldn't need a bunch of new pointer versions for each integer operation...)

Cc @nikic

[nikic]

LLVM currently doesn't have something like addr because the necessary analysis infrastructure to capitalize on it isn't in place (yet). LLVM currently combines address capture and provenance escape into one concept, and the addr vs ptrtoint distinction only really becomes relevant once you separate them. This is something I have on my long term TODO list, but never get around to...

[RalfJung]

Makes sense, thanks for the update! (Sorry for saying "just support", I did not mean to imply that this is easy.)