You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I Would Be Great If C2Rust could just translate C11 atomics (extern _Atomic int foo; foo = 4;).
While personally I prefer to go through the explicitly ordering functions (atomic_fetch_and_explicity etc), atomic types are often part of existing libraries, especially stdatomic.h.
Atomics behave a lot like qualifiers, but LLVM doesn't seem to store them that way -- and adding a bit to the qualifiers set doesn't seem to be planned there (as the qualifiers are mixed in with the identifier). Thus they probably need to go through a new CTypeKind, which the referenced branch contains a commit to introduce.
Eventually (didn't get to that point yet), we'd end up with something that looks like Atomic<short>. It's bad enough that it's hard to tell which sizes the target platform actually has atomics support for (not that we could do anything about it here), but it's worse that the information about the actual size (and thus concrete type, such as AtomicU16) to use is unavailable without knowing the target. I think the best option will be to use a trait (Atomic<T>) that relies on the wrapped elements being type aliases for any actually atomicable type, and let things err out at compilation time (when the target is known) otherwise. We might use the atomig crate or roll our own (but I don't see why we should).
I think that the primary goal here should be to support simple numeric atomics in their C11 form; _Atomic struct foo is something I wouldn't put much effort in (but of course it's nice if it just happens to work).
The text was updated successfully, but these errors were encountered:
I Would Be Great If C2Rust could just translate C11 atomics (
extern _Atomic int foo; foo = 4;
).While personally I prefer to go through the explicitly ordering functions (
atomic_fetch_and_explicity
etc), atomic types are often part of existing libraries, especiallystdatomic.h
.I've started toying with these at https://github.com/chrysn-pull-requests/c2rust/tree/atomics (building on the latest state of #302), and found a few aspects that I couldn't immediately solve:
Atomic<short>
. It's bad enough that it's hard to tell which sizes the target platform actually has atomics support for (not that we could do anything about it here), but it's worse that the information about the actual size (and thus concrete type, such asAtomicU16
) to use is unavailable without knowing the target. I think the best option will be to use a trait (Atomic<T>
) that relies on the wrapped elements being type aliases for any actually atomicable type, and let things err out at compilation time (when the target is known) otherwise. We might use the atomig crate or roll our own (but I don't see why we should).I think that the primary goal here should be to support simple numeric atomics in their C11 form;
_Atomic struct foo
is something I wouldn't put much effort in (but of course it's nice if it just happens to work).The text was updated successfully, but these errors were encountered: