-
Notifications
You must be signed in to change notification settings - Fork 870
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
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.