-
Notifications
You must be signed in to change notification settings - Fork 818
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 safety comments #1651
Add safety comments #1651
Conversation
Does the referenced UCG discussion 412 apply to this case? Exercising the offending code under miri with and without the flags mentioned in the issue does not make a difference.
|
@sftse IIRC miri doesn't currently do anything special around Vecs in this way, so it's not useful to rely on it for whether the rules apply. I did mention "this and related issues" because I know this type of thing has been the subject of discussion. For now I'm comfortable giving a sense of "this is potentially but not probably problematic" |
This may have been poor wording on my part, and may have communicated that miri thinks the code is fine. What I meant is under both the liberal and more restrictive validity rules for references, miri does not think the code is fine. If this was not a misunderstanding, this reply would be very puzzling to me and would hope you can expand on that. |
It's worth pointing out that this appears to not even be something solely detectable by miri. Prior to commit 4322056 rustc would refuse to compile this crate, as mentioned in #1485. That commit, although not introducing any relevant changes to the unsafe block, managed to successfully subvert rustc's detection of this UB pattern. |
Oh! The & to &mut transmute is the problem, I see. We can use Given that I might just write it with manual unsafe (which would not be open to recusrive validity issues or transmute issues) then. |
I attempted a fix. |
The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update. |
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.
Thanks a lot both! 🤗 quite honored to see core rust people here 👀
LGTM!
unsafe { | ||
assert!(i < words_len); | ||
// This is words[i], but avoids needing to go through &T (which triggers UB) |
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.
FMI, why is &T
UB?
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.
It's UB to mutate data that currently has an active &T
. This persists through raw pointers in some ways (and not in others).
|
seems to cause an issue with compilation, not sure if it's actionable on my side |
Fixed |
Thanks! |
I recently performed safety review on 0.19. Besides finding the already-fixed #1491, I also found that these cases of unsafety were a bit hard to disentangle, and documented them further.