-
-
Notifications
You must be signed in to change notification settings - Fork 80
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
Zeroable should be implemented for Atomic*
#74
Comments
If it's unsafe to cast &usize to &AtomicUsize then the AtomicUsize type doesn't fit with Pod, because Pod allows casting between &T and &U when the size and alignment match. Similarly, the TransparentWrapper trait isn't appropriate. It's fine to have Zeroable, I suppose. |
I think it might make sense to have new traits for immutable access, since that would allow safe casts to/from I'll put a PR in to implement |
I don't think you should read atomic values non-atomically. |
Atomic*
Atomic*
Yeah, very good point. Well, at least zeroable should be implemented. |
* `impl Zeroable for Atomic*` fixes Lokathor#74 * added feature flag for `zeroable_atomics` Added documentation for some feature flags on the `Zeroable` trait. Also fixed some invalid references in doc-comments.
The atomic types are all bytemuck-compatible, and in fact as far as I know all bytemuck traits can be implemented for
Atomic*
that can be implemented for the underlying integer type as the operations available on the atomic types are a strict superset (i.e. setting their value via an immutable reference). Even casting between a non-atomic int and an atomic int should be safe, although from this discussion here rust-lang/rust#76314 it may be invalid to cast an&usize
(or other scalar) to an&AtomicUsize
(or other atomic scalar). This sadly means thatPod
cannot be implemented without adding new traits to account for types where owned types can be cast but references cannot.The text was updated successfully, but these errors were encountered: