Clang Thread Safety: False positive warning generated in C code when accessing fields of a struct

[DobroSun]

// Compiling with: clang -Wthread-safety main.c
struct __attribute__((lockable)) Mutex {};
struct Foo {
    struct Mutex mu;
    int value __attribute__((guarded_by(mu)));
};

void mutex_lock(struct Mutex* mu)   __attribute__((exclusive_lock_function(mu)));
void mutex_unlock(struct Mutex* mu) __attribute__((unlock_function(mu)));

struct Mutex mu;
int value __attribute__((guarded_by(mu)));

int main() {
    {
        mutex_lock(&mu);
        value = 123;      // Works!
        mutex_unlock(&mu);
    }

    {
        struct Foo foo = {};
        mutex_lock(&foo.mu);
        foo.value = 123;     // warning: writing variable 'value' requires holding mutex 'mu' exclusively [-Wthread-safety-analysis]
        mutex_unlock(&foo.mu);
    }
    return 0;
}

Compiled on Fedora 42 with clang 20.1.8, although I tried clang 21.1.2 and the issue still persists.
Renaming file to main.cpp and compiling with clang++ doesn't generate this kind of error. Maybe I'm doing something here incorrectly or is this actually a compiler bug? Can't tell myself...

[AaronBallman]

CC @melver @aaronpuchert

[melver]

The rules for using guarded_by to refer to struct members in C are not that well documented - this works:

--- ../thread-safety.c  2025-10-06 20:45:52.200103634 +0200
+++ ../thread-safety2.c 2025-10-06 20:46:17.324408501 +0200
@@ -2,7 +2,7 @@
 struct __attribute__((lockable)) Mutex {};
 struct Foo {
     struct Mutex mu;
-    int value __attribute__((guarded_by(mu)));
+    int value __attribute__((guarded_by(&mu)));
 };

 void mutex_lock(struct Mutex* mu)   __attribute__((exclusive_lock_function(mu)));

The task here is for us to document that better or figure out if there's a way to do the right thing without the & in C. I believe the analysis was fundamentally designed for C++, where it uses the implicit this pointer to understand that guarded_by(mu) refers to a specific object's member, but in a C struct there is no implicit this we could ever refer to to make this work.

[AaronBallman]

The task here is for us to document that better or figure out if there's a way to do the right thing without the & in C. I believe the analysis was fundamentally designed for C++,

Yeah, the original analysis was designed with C++ in mind.

where it uses the implicit this pointer to understand that guarded_by(mu) refers to a specific object's member, but in a C struct there is no implicit this we could ever refer to to make this work.

CC @rapidsna @bwendling because this relates to bounds safety attributes with the same issues.

[rapidsna]

Also CC @pdherbemont who implemented #94216. I thought __attribute__((guarded_by(mu))); was supposed to work with his implementation. While C doesn't have an implicit this, that doesn't explain why guarded_by(&mu) works and guarded_by(mu) doesn't. So it sounds like an unintentional bug to me.