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 pointer::mask #98290

Open
1 of 3 tasks
WaffleLapkin opened this issue Jun 20, 2022 · 5 comments
Open
1 of 3 tasks

Tracking Issue for pointer::mask #98290

WaffleLapkin opened this issue Jun 20, 2022 · 5 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

@WaffleLapkin
Copy link
Member

WaffleLapkin commented Jun 20, 2022

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

Unresolved Questions

  • None yet.
@WaffleLapkin WaffleLapkin 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 Jun 20, 2022
@hsanzg
Copy link

hsanzg commented Jul 21, 2024

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
Copy link
Member

RalfJung commented Jul 21, 2024

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
Copy link
Member

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
Copy link
Contributor

nikic commented Sep 14, 2024

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
Copy link
Member

RalfJung commented Sep 14, 2024 via email

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