================
@@ -339,6 +425,36 @@ void
BlockInCriticalSectionChecker::reportBlockInCritSection(
os.str(), ErrNode);
R->addRange(Call.getSourceRange());
R->markInteresting(Call.getReturnValue());
+ // for 'read' call, check whether it's file descriptor(first argument) is
+ // created by 'open' API with O_NONBLOCK flag and don't report for this
+ // situation.
+ if (Call.getCalleeIdentifier()->getName() == "read") {
+ do {
+ const auto *arg = Call.getArgExpr(0);
+ if (!arg)
+ break;
+
+ const auto *DRE = dyn_cast<DeclRefExpr>(arg->IgnoreImpCasts());
----------------
Xazax-hun wrote:
I see. Unfortunately, matching on the memory region might not be the most
reliable.
Having things like `int a = b;` would move the value in a new memory region.
Also, matching the AST in the bug reporter visitor is fragile as there are many
ways to express something.
E.g., imagine if someone has some logging and does something like `int fd =
LOG(open(...))` where the `LOG` macro inserts some extra code? In general, we
should try to do as little matching on the AST as possible and should rely in
the symbols when we can.
So my proposal would be to maintain a set of symbols in the analysis state.
After each `open` call look at the returned symbol, and in case it was
returning a non-blocking file descriptor put that symbol in the set.
When we report a problem check if the file descriptor we use to report the
problem is in the set.
This works great for symbolic file descriptors. Unfortunately, this might break
down for concrete integers like 1. But I am wondering if that is a rare edge
case enough that we might not need to support. I'd expect open to almost always
return a symbolic value. What do you think?
https://github.com/llvm/llvm-project/pull/126752
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
