-
Notifications
You must be signed in to change notification settings - Fork 13.4k
Tracking Issue for pointer_is_aligned_to #96284
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
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 |
Uh oh!
There was an error while loading. Please reload this page.
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: