-
-
Notifications
You must be signed in to change notification settings - Fork 7
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
AtomicBox should have bounds on its Send/Sync traits #15
Comments
Heads up: this issue has been included in the RustSec advisory database. It will be surfaced by tools such as cargo-audit or cargo-deny from now on. Once a fix is released to crates.io, please open a pull request to update the advisory with the patched version, or file an issue on the advisory database repository. |
Hey! thanks for opening the issue. You're correct! I think @vertexclique has a patch and we can roll it out hopefully soon |
Added a regression test thanks to trybuild, super nice crate, i didn't know about it! |
@vertexclique can we close this now ? :) I'm going to submit a aptch to the rustsec advisory database |
Truly, let's close it. |
Currently
AtomicBox
implements the Sync/Send traits unconditionally:lever/src/sync/atomics.rs
Lines 104 to 105 in 15a96c7
I think this should only be when
T: Sized + Sync
andT: Sized + Send
respectively. Otherwise, this makes it possible to send across types that aren't safe to use across threads such asCell
s. Here's a demonstration that causes a data-race:This outputs:
(Issue found by @sslab-gatech's Rust group)
The text was updated successfully, but these errors were encountered: