Skip to content

Add Sync trait on structs used in globals#65

Closed
lucic71 wants to merge 6 commits into
Cpp2Rust:masterfrom
lucic71:pointer-sync
Closed

Add Sync trait on structs used in globals#65
lucic71 wants to merge 6 commits into
Cpp2Rust:masterfrom
lucic71:pointer-sync

Conversation

@lucic71
Copy link
Copy Markdown
Contributor

@lucic71 lucic71 commented May 10, 2026

To compile structs used in globals that contain raw pointers, we need to add the Sync marker trait.

@lucic71 lucic71 marked this pull request as draft May 10, 2026 14:34
@lucic71
Copy link
Copy Markdown
Contributor Author

lucic71 commented May 10, 2026

This is incomplete, it only solves part of the problem.

In Rust, static global variables require Sync so that multiple threads can take an immutable reference to the static storage, static mut global variables don't require Sync because it's by itself unsafe to access the static mut storage.

This PR solved the problem for static global struct objects that contained raw pointers. Raw pointers are not Sync in Rust so any struct containing them needs to implement the Sync trait. What this PR does not solve is global arrays containing pointers in static storage, for example [*const T; N].

One solution would be to translate the const global variables as const instead of static. However const global variables don't have a stable address in the final binary. Other solution would be to wrap the array in a newtype, but this makes later usages of the array harder in the codegen.

None of the two above solution is complete. For the moment we can translate all global variables as static mut instead of static so that we don't have to implement Sync for them. By construction, the generated code is guaranteed not to modify the global variable, even if it's declared as static mut instead of static.

This only touches the unsafe model.

@lucic71 lucic71 closed this May 10, 2026
nunoplopes pushed a commit that referenced this pull request May 10, 2026
This is a continuation of #65:

> This is incomplete, it only solves part of the problem.
> 
> In Rust, `static` global variables require `Sync` so that multiple
threads can take an immutable reference to the `static` storage, `static
mut` global variables don't require `Sync` because it's by itself unsafe
to access the `static mut` storage.
> 
> This PR solved the problem for `static` global struct objects that
contained raw pointers. Raw pointers are not `Sync` in Rust so any
struct containing them needs to implement the `Sync` trait. What this PR
does not solve is global arrays containing pointers in `static` storage,
for example `[*const T; N]`.
> 
> One solution would be to translate the const global variables as
`const` instead of `static`. However `const` global variables don't have
a stable address in the final binary. Other solution would be to wrap
the array in a newtype, but this makes later usages of the array harder
in the codegen.
> 
> None of the two above solution is complete. For the moment we can
translate all global variables as `static mut` instead of `static` so
that we don't have to implement `Sync` for them. By construction, the
generated code is guaranteed not to modify the global variable, even if
it's declared as `static mut` instead of `static`.
> 
> This only touches the unsafe model.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant