Skip to content

Comment on Rc abort-guard strategy without naming unrelated fn #140483

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.

Sign up for GitHub

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

Merged
merged 2 commits into from
May 7, 2025
Merged

Comment on Rc abort-guard strategy without naming unrelated fn #140483

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
dd20225
Update rc.rs docs
baumanj Apr 29, 2025
6a4af82
Update rc.rs docs
baumanj May 6, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion library/alloc/src/rc.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3536,7 +3536,7 @@ impl<T> Default for Weak<T> {
}
}

// NOTE: We checked_add here to deal with mem::forget safely. In particular
// NOTE: We wrapping_add here to deal with mem::forget safely. In particular
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is confusing in a different way: the wrapping_add does not offer the protection anymore, the strong == 0 conditional does.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

at the very least, it should mention clearly what actually implements the guard that handles the mem::forget, if it's going to mention any code.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see what you mean. The fact that it's wrapping_add rather than checked_add previously is merely a detail for the sake of code generation, and that's addressed in a more local comment. In that case, I think this comment is more about the higher level issue of a potential soundness hole and isn't enhanced by mentioning the particular implementation details. How about this?

// NOTE: If you mem::forget Rcs (or Weaks), drop is skipped and the ref-count
// is not decremented, meaning the ref-count can overflow, and then you can
// free the allocation while outstanding Rcs (or Weaks) exist, which would be
// unsound. We abort because this is such a degenerate scenario that we don't
// care about what happens -- no real program should ever experience this.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, something like that seems good to me.

// if you mem::forget Rcs (or Weaks), the ref-count can overflow, and then
// you can free the allocation while outstanding Rcs (or Weaks) exist.
// We abort because this is such a degenerate scenario that we don't care about
Expand Down
Loading