-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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_is_aligned_to #96284
Comments
For the unresolved question: another option might be to expose https://stdrs.dev/nightly/x86_64-unknown-linux-gnu/core/mem/valid_align/struct.ValidAlign.html and use it as the parameter type. |
I want to propose to stabilize these methods! (can someone open an fcp?) Stabilization reportImplementation History
API Summaryimpl *const T {
pub fn is_aligned(self) -> bool where T: Sized;
pub fn is_aligned_to(self, align: usize) -> bool;
}
// ... and the same for` *mut T` Experience Report#100820 and #100823 refactored some std code into using these methods simplifying the code. These methods were long requested (see for example #56304) and seem to be quite nice to use. They also may have slightly better codegen, compared to naive |
I think the unresolved question needs an answer, not just a mention. As I brought up earlier, I think it'd be really nice to have a type for valid alignments. The other two options are both unfortunate, IMHO: needing to |
So, our options for resolving the unresolved question:
I'm leaning towards 2, but that's just me 🤷 |
Could these methods be made |
@tyler274 they can't, CTFE engine (compile time function execution) does not (necessarily) have a notion of "address" of a pointer. Since you can't take the address (e.g. it's UB to |
That's assuming it would be stored as EDIT: I opened an ACP to add an |
Question from the libs-api meeting: How often would one use How often does one want to check a calculated alignment rather than a constant alignment? With e.g. |
Status update: I originally planned to use grep.app or an alternative to gather stats about "is aligned" checks in the wild. But... I did not have enough courage to finish the work and now I simply do not have the capacity for that. If anyone wants to take this from here (and answer t-libs-api questions in the above post) — feel free to. |
Can |
The standard library currently only uses I searched grep.app as Waffle suggests above, and I only found these callers that could not easily port to https://github.com/jamwaffles/linuxcnc-hal-rs/blob/0aac97869278fd90a7e3857226cb8ebd4ce89123/linuxcnc-hal/src/hal_pin/hal_pin.rs#L33-L45 But also, those 3 projects are not even using the unstable At this time, I do not think that the |
Per rust-lang#96284 (comment) this API is a mess and is regarded as insufficiently motivated. Removing it from the public API is potentially the only blocker on stabilizing its pleasant brother .is_aligned(). I initially just deleted it completely but it's since become Heavily Used for the purposes of assert_unsafe_precondition, and there's clearly Some Stuff going on with that API that I have no interest in poking.
Per rust-lang#96284 (comment) this API is a mess and is regarded as insufficiently motivated. Removing it from the public API is potentially the only blocker on stabilizing its pleasant brother .is_aligned(). I initially just deleted it completely but it's since become Heavily Used for the purposes of assert_unsafe_precondition, and there's clearly Some Stuff going on with that API that I have no interest in poking.
Per rust-lang#96284 (comment) this API is a mess and is regarded as insufficiently motivated. Removing it from the public API is potentially the only blocker on stabilizing its pleasant brother .is_aligned(). I initially just deleted it completely but it's since become Heavily Used for the purposes of assert_unsafe_precondition, and there's clearly Some Stuff going on with that API that I have no interest in poking.
Per rust-lang#96284 (comment) this API is a mess and is regarded as insufficiently motivated. Removing it from the public API is potentially the only blocker on stabilizing its pleasant brother .is_aligned(). I initially just deleted it completely but it's since become Heavily Used for the purposes of assert_unsafe_precondition, and there's clearly Some Stuff going on with that API that I have no interest in poking.
Per rust-lang#96284 (comment) this API is a mess and is regarded as insufficiently motivated. Removing it from the public API is potentially the only blocker on stabilizing its pleasant brother .is_aligned(). I initially just deleted it completely but it's since become Heavily Used for the purposes of assert_unsafe_precondition, and there's clearly Some Stuff going on with that API that I have no interest in poking.
I propose we split the feature into two and stabilize the perfectly inoffensive |
Feature gate:#![feature(pointer_is_aligned)]
Feature gate:
#![feature(pointer_is_aligned_to)]
This is a tracking issue for
ptr.is_aligned()
andptr.is_aligned_to(alignment)
.Public API
Steps / History
pointer_is_aligned
:pointer_is_aligned_to
:NonNull
method to this gate Stabilizenon_null_convenience
#124498Unresolved Questions
The text was updated successfully, but these errors were encountered: