NoQ requested changes to this revision.
NoQ added inline comments.
This revision now requires changes to proceed.


================
Comment at: clang/test/Analysis/Checkers/CPlusPlus11LockChecker.cpp:379-382
+void rm_bad1() {
+  rm1.lock(); // no-warning
+  rm1.lock(); // expected-warning{{This lock has already been acquired}}
+}
----------------
ASDenysPetrov wrote:
> NoQ wrote:
> > I repeat, this is a false positive. Recursive mutexes can be locked twice, 
> > that's the whole point.
> Yes, I remember. I think you've mixed up with my previous attempts of 
> introducting a new checks for recursive mutexes.
> This is not this case. This kind of checks already exists in 
> PthreadLockChecker before.
> I've just reused this check for all kind of STL mutexes.
> 
> If you look at `void bad1()` in clang\test\Analysis\pthreadlock.c you can 
> find the same case.
>  I've just reused this check for all kind of STL mutexes.

You're taking code for mushing potatoes and applying it to differential 
calculus.

Different kinds of mutexes behave differently. This is not the same case. That 
test is a true positive because that mutex is non-recursive, your test is a 
false positive because your mutex is recursive. In that test the program 
immediately hangs and there's no valid way to unhang it, in your test the 
programmer simply has to unlock the mutex twice and they're good to go.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D85984/new/

https://reviews.llvm.org/D85984

_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to