================
@@ -2681,27 +2693,16 @@ void MallocChecker::HandleOffsetFree(CheckerContext &C,
SVal ArgVal,
void MallocChecker::HandleUseAfterFree(CheckerContext &C, SourceRange Range,
SymbolRef Sym) const {
-
- if (!ChecksEnabled[CK_MallocChecker] && !ChecksEnabled[CK_NewDeleteChecker]
&&
- !ChecksEnabled[CK_InnerPointerChecker]) {
- C.addSink();
- return;
- }
----------------
NagyDonat wrote:
I'm pretty sure that the _intention_ behind this block (and analogous blocks)
is that it tries to create a sink node when the checker part that would create
a bug report is disabled -- but this isn't the actual behavior of this code
fragment.
As a concrete example, in the test file `new.cpp` there was a symbol (`Sym`)
allocated with `operator new`, `NewDeleteChecker` was disabled, but
`MallocChecker` (the checker part `unix.Malloc`) was enabled. In this situation
the revision before this PR:
- (1) didn't create a sink because `ChecksEnabled[CK_MallocChecker]` was true;
- (2) returned a bit later when `getCheckIfTracked` returned `std::nullopt`.
After this PR `getRelevantFrontendAs<>` will find the frontend that corresponds
to the `UseFree` bug type and the given `Sym`bol (that is, `NewDeleteChecker`)
and `handleNullOrDisabled` will recognize that there _is_ a relevant frontend,
but it's disabled, so it will create a sink before the early return.
https://github.com/llvm/llvm-project/pull/147080
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
