-
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
Document unsafety in core::slice::memchr #76688
Conversation
r? @KodrAus (rust_highfive has picked a reviewer for you, use r? to override) |
It looks like CI is failing here, but this looks good to me. I think you may have raced with #76488, though. I'm happy to accept either, whichever one is ready first probably :) |
Hi @yokodake 👋 It looks like we've got a few failing tidy checks on this one:
|
@rustbot modify labels to +S-waiting-on-author and -S-waiting-on-review |
Sorry didn't knew about these tidy checks. |
☔ The latest upstream changes (presumably #76971) made this pull request unmergeable. Please resolve the merge conflicts. Note that reviewers usually do not review pull requests until merge conflicts are resolved! Once you resolve the conflicts, you should change the labels applied by bors to indicate that your PR is ready for review. Post this as a comment to change the labels:
|
It looks like we've refactored our @yokodake would you like to rebase your PR? |
Contributes to rust-lang#66219
@rustbot modify labels: +S-waiting-on-author -S-waiting-on-review |
Ah my bad! Looks like the rebase did happen 🙂 @rustbot modify labels: -S-waiting-on-author +S-waiting-on-review |
📌 Commit a506461 has been approved by |
⌛ Testing commit a506461 with merge ba432fcfbe3d11cf6a4ef766effdb5c7da044ad8... |
💔 Test failed - checks-actions |
@bors r- The PR failed but bors forgot about that during synchronize. |
What kind of test could have failed, I only added comments. |
@bors retry |
@bors r=kodrAus |
📌 Commit a506461 has been approved by |
@@ -105,6 +105,8 @@ pub fn memrchr(x: u8, text: &[u8]) -> Option<usize> { | |||
let (min_aligned_offset, max_aligned_offset) = { | |||
// We call this just to obtain the length of the prefix and suffix. | |||
// In the middle we always process two chunks at once. | |||
// SAFETY: transmuting `[u8]` to `[usize]` is safe except for size differences | |||
// which are handled by `align_to`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's only safe if the [u8]
is correctly aligned (and has a size that holds an integer multiple of usize
s as you write here AFAIU). Might be worth mentioning that align_to
also takes care of aligning properly (does it?).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The more precise safety condition would be that [u8; size_of::<usize>]
has the same validity invariants as usize, but I would not block on that in this PR.
☀️ Test successful - checks-actions |
Contributes to #66219
Note sure if that's good enough, especially for the
align_to
call.The docs only mention transmuting and I don't think that everything related to reference lifetimes and state validity mentioned in the nomicon are relevant here.