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

Be aware of alignment checking issues #182

Open
joshlf opened this issue May 24, 2023 · 0 comments
Open

Be aware of alignment checking issues #182

joshlf opened this issue May 24, 2023 · 0 comments
Labels
compatibility-nonbreaking Changes that are (likely to be) non-breaking

Comments

@joshlf
Copy link
Member

joshlf commented May 24, 2023

We have code like the following in zerocopy as of this writing:

zerocopy/src/lib.rs

Lines 2323 to 2331 in 27aea67

/// Is `t` aligned to `mem::align_of::<U>()`?
#[inline(always)]
fn aligned_to<T: AsAddress, U>(t: T) -> bool {
// `mem::align_of::<U>()` is guaranteed to return a non-zero value, which in
// turn guarantees that this mod operation will not panic.
#[allow(clippy::arithmetic_side_effects)]
let remainder = t.addr() % mem::align_of::<U>();
remainder == 0
}

According to rust-lang/rust#62420, there's a small chance that this may be decided to be unsound (and it's not supported during const eval, although there are bigger problems regarding using addresses in const eval). We should figure out whether this is a risk we're comfortable with, and consider how we might mitigate it.

@joshlf joshlf added the compatibility-nonbreaking Changes that are (likely to be) non-breaking label Aug 12, 2023
@joshlf joshlf mentioned this issue Aug 20, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compatibility-nonbreaking Changes that are (likely to be) non-breaking
Projects
None yet
Development

No branches or pull requests

1 participant