[LLVMbugs] [Bug 18388] New: False positive null pointer dereference, comparison against pointer that can be null in loop
bugzilla-daemon at llvm.org
bugzilla-daemon at llvm.org
Sun Jan 5 02:21:08 PST 2014
http://llvm.org/bugs/show_bug.cgi?id=18388
Bug ID: 18388
Summary: False positive null pointer dereference, comparison
against pointer that can be null in loop
Product: clang
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Static Analyzer
Assignee: kremenek at apple.com
Reporter: daniel.marjamaki at evidente.se
CC: llvmbugs at cs.uiuc.edu
Classification: Unclassified
CLANG revision: 198553.
Reduced example code:
struct Token {
Token *next() const;
Token *linkAt(int) const;
static bool Match(const Token *tok, const char pattern[], unsigned int
varId=0);
char *str;
};
struct Variable { const Token *nameToken() const; };
void CheckStlIterators(const Variable *var, unsigned int iteratorId)
{
const Token* validatingToken = 0;
for (const Token *tok2 = var->nameToken(); tok2 != var->nameToken(); tok2 =
tok2->next()) {
if (Token::Match(tok2, "%varid% = %var% . erase (", iteratorId))
validatingToken = tok2->linkAt(5);
if (tok2 == validatingToken) {}
if (tok2->str) {}
}
}
As far as I see (from my experience reducing the code), the false positive is
written because tok2 is compared against validatingToken in the loop which can
be NULL. However the validatingToken is NULL by intention when it is
"disabled". It is set to a non-NULL value in the loop when it is activated.
Original source code:
https://github.com/danmar/cppcheck/blob/1b0dd00/lib/checkstl.cpp#L67
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20140105/a0547f2e/attachment.html>
More information about the llvm-bugs
mailing list