Skip to content

Conversation

@michael-schwarz
Copy link
Member

Fixes #1072 and the unsoundness described there.

@jerhard
Copy link
Member

jerhard commented Jul 9, 2023

Does marking thread-locals variables as non-unique also lead to them being only weakly updated? If so, could one treat thread-local variables as non-unique only when they are escaped, to remedy this issue?

It should not be possible to have address comparisons between multiple instances of a particular type of thread-local variable without one of them having escaped.

@sim642 sim642 added the c11 label Jul 9, 2023
@michael-schwarz
Copy link
Member Author

Does marking thread-locals variables as non-unique also lead to them being only weakly updated? If so, could one treat thread-local variables as non-unique only when they are escaped, to remedy this issue?

The weak update mechanism applies mainly to locals, here the variables are still treated as globals (pending a more systematic approach). However, I added a test whether this thread-local variable has its address taken, which was also the proxy we used for having escaped in #1071. I tried for a bit, but could not really construct any examples where that really makes a difference. I still think it is good to have it in the interest of consistency though.

@michael-schwarz michael-schwarz requested a review from jerhard July 10, 2023 08:12
@sim642 sim642 added this to the v2.2.0 milestone Jul 12, 2023
@michael-schwarz michael-schwarz merged commit 3410ca0 into master Jul 14, 2023
@michael-schwarz michael-schwarz deleted the issue_1072 branch July 14, 2023 08:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Address comparisons unsound for thread-local variables

4 participants