aaronpuchert wrote:

> The equivalent of passing a `pt_guarded_by` variable by value doesn't seem to 
> warn.

This inconsistency is probably my largest concern. If you have
```c
int x GUARDED_BY(mu);
int *p PT_GUARDED_BY(mu);
```
then `&x` should basically behave like `p`, and `x` like `*p`. But with the 
current implementation, that cannot be the case, because `p` is just a no-op.

That's why I think we should rather check function arguments, and warn on 
passing (1) the address of a guarded variable, (2) a pointee-guarded variable. 
There is already functionality that makes sure (1) and (2) work together: 
`checkAccess` and `checkPtAccess` call each other when necessary. This doesn't 
seem to handle unary `&` at the moment, but I suppose this would be easy to 
add. The check for passing arguments itself is in `examineArguments`. We 
currently only check reference type arguments:
```c++
    if (Qt->isReferenceType())
      checkAccess(*Arg, AK_Read, POK_PassByRef);
```
Here we might simply add a branch for pointer types with the appropriate `POK` 
that you already introduced (though we might need to rename it slightly).

This still doesn't cover local pointer variables, but here I guess we need a 
better understanding of the patterns and how much alias analysis we'd need to 
unravel them. Local pointer variables as obfuscation device are hopefully not 
common, so there is likely some more complex logic that would be intractable 
for us anyway. So I'd be curious to see some interesting examples.

https://github.com/llvm/llvm-project/pull/123063
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to