-
Notifications
You must be signed in to change notification settings - Fork 20
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
Add a specific type for pointer alignment #108
Comments
This seems reasonable. The only thing I'm wondering is how specific this type should be to alignment of types, versus be more like a more general "PowerOfTwoUsize" (similar to our NonZero types). However, that very quickly explodes into all kind of sets of integers, so we should probably not go that route. Splitting the 'is power of two'-check off into a separate type seems like a great thing. I like how the value of @rustbot second |
Right. I really didn't want to get into "should there be Thanks for the second! I'll get started on a PR. |
Add `ptr::Alignment` type Essentially no new code here, just exposing the previously-`pub(crate)` `ValidAlign` type under the name from the ACP. ACP: rust-lang/libs-team#108 Tracking Issue: rust-lang#102070 r? `@ghost`
Add `ptr::Alignment` type Essentially no new code here, just exposing the previously-`pub(crate)` `ValidAlign` type under the name from the ACP. ACP: rust-lang/libs-team#108 Tracking Issue: rust-lang#102070 r? ``@ghost``
This is merged to nightly, so I'll close the ACP. Please reopen if it should stay around. |
Add `ptr::Alignment` type Essentially no new code here, just exposing the previously-`pub(crate)` `ValidAlign` type under the name from the ACP. ACP: rust-lang/libs-team#108 Tracking Issue: rust-lang/rust#102070 r? ``@ghost``
Proposal
Problem statement
We often use
usize
to represent the alignment of a type. However, on a 64-bit machine there are only 64 valid alignments, which is under 0.000_000_000_000_000_35% of the valid values of the type -- and, realistically, there are only ≈10 useful alignments. (Sure, it's legal to writerepr(align(1152921504606846976))
, but nobody ever would.)It's also common to use the special property of valid alignments -- that they're powers of two -- to optimize various operations in ways that produce meaningless results for other values. For example,
ptr % align
is written asptr & (align - 1)
, but that has "no meaning" for invalid alignment values.With a custom type for alignments we can provide APIs that can safely take advantage of these properties.
Motivation, use-cases
Layout::padding_needed_for
takesalign: usize
, and thus needs the noteif it took a specific alignment type, that wouldn't be a concern. And needing to call
.pading_needed_for(Alignment::of::<T>())
(say) instead of.padding_needed_for(align_of::<T>())
is no hardship for the caller.Similarly,
<*const T>::is_aligned_to
also takesalign: usize
, and its tracking issue (rust-lang/rust#96284) has an open question about how to handle invalid alignments passed to it.Already today,
Layout
requires that its alignment be a valid alignment. Having a type with the invariant that it's a valid alignment allowed making a method safe when it would have otherwise requiredunsafe
(rust-lang/rust#99117 (comment)).Solution sketches
I propose something like the following type:
There's a variety of additional things that could go along with that, but aren't essential from the start, like
NonZeroUsize
from the alignmentFrom
/TryFrom
s to go with thenew
slog2
to turn alignments into0, 1, 2, 3, …
instead of1, 2, 4, 8, …
*const T: Mod<Alignment, Output = usize>
Layout
to expose the internalAlignment
and create from anAlignment
(thus avoiding thealign.is_power_of_two()
check in its safe constructor).Links and related work
A type for this already exists internally in
core
: https://github.com/rust-lang/rust/blob/master/library/core/src/mem/valid_align.rsWhat happens now?
This issue is part of the libs-api team API change proposal process. Once this issue is filed the libs-api team will review open proposals in its weekly meeting. You should receive feedback within a week or two.
The text was updated successfully, but these errors were encountered: