Remove check on strong_count < 1. #32
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Previously, we tried to check against the possibility that C code calls rustls_client_config_free twice. We did this by doing `Arc::from_raw`, then checking if strong_count is < 1. However, this was undefined behavior: deferencing a dangling pointer. https://doc.rust-lang.org/reference/behavior-considered-undefined.html If strong_count went to zero on some previous call, `Arc` would have dropped its contents. That means the pointed-to memory is no longer valid to access, and its contents are undefined. So we might see strong_count of 1,000,000, or -1,000,000, or any other value; or monkeys could fly out of our noses. The C caller can still invoke undefined behavior by calling `rustls_client_config_free` twice, but the previous change tried to detect undefined behavior by invoking undefined behavior, which doesn't work.
|
Thanks to @alex for pointing this out in #1 (comment). |
jsha
changed the title
tgeoghegan
approved these changes
Feb 1, 2021
jsha
added a commit
that referenced
this pull request
Mar 12, 2021
Order imports as: std, third-party, crate. Use `try_ref_from_ptr!` to turn `out_n`'s into refs. This moves unsafe blocks from later in the function to earlier in the function, closer to where their safety properties are checked. Also, remove pre-emptive zeroing of `out_n`'s. According to the conventions listed in our README, there are no partial successes or partial failures, so we shouldn't write to `out_n` if we early-return. Remove `strong_count < 1` checks on Arc. Follow-up from #32. Add some missing comments and fix some formatting.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Previously, we tried to check against the possibility that C code calls
rustls_client_config_free twice. We did this by doing
Arc::from_raw,then checking if strong_count is < 1.
However, this was undefined behavior: deferencing a dangling pointer.
https://doc.rust-lang.org/reference/behavior-considered-undefined.html
If strong_count went to zero on some previous call,
Arcwould havedropped its contents. That means the pointed-to memory is no longer
valid to access, and its contents are undefined. So we might see
strong_count of 1,000,000, or -1,000,000, or any other value; or monkeys
could fly out of our noses.
The C caller can still invoke undefined behavior by calling
rustls_client_config_freetwice, but the previous change tried todetect undefined behavior by invoking undefined behavior, which doesn't
work.