maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/Analysis/inlining/false-positive-suppression.c

299 lines
6.7 KiB
C
Raw Normal View History

[analyzer] Suppress bugs whose paths go through the return of a null pointer. This is a heuristic intended to greatly reduce the number of false positives resulting from inlining, particularly inlining of generic, defensive C++ methods that live in header files. The suppression is triggered in the cases where we ask to track where a null pointer came from, and it turns out that the source of the null pointer was an inlined function call. This change brings the number of bug reports in LLVM from ~1500 down to around ~300, a much more manageable number. Yes, some true positives may be hidden as well, but from what I looked at the vast majority of silenced reports are false positives, and many of the true issues found by the analyzer are still reported. I'm hoping to improve this heuristic further by adding some exceptions next week (cases in which a bug should still be reported). llvm-svn: 164449
2012-09-22 09:25:06 +08:00
// RUN: %clang_cc1 -analyze -analyzer-checker=core -analyzer-config suppress-null-return-paths=false -verify %s
[analyzer] New option to not suppress null return paths if an argument is null. Our one basic suppression heuristic is to assume that functions do not usually return NULL. However, when one of the arguments is NULL it is suddenly much more likely that NULL is a valid return value. In this case, we don't suppress the report here, but we do attach /another/ visitor to go find out if this NULL argument also comes from an inlined function's error path. This new behavior, controlled by the 'avoid-suppressing-null-argument-paths' analyzer-config option, is turned off by default. Turning it on produced two false positives and no new true positives when running over LLVM/Clang. This is one of the possible refinements to our suppression heuristics. <rdar://problem/12350829> llvm-svn: 166941
2012-10-30 01:31:59 +08:00
// RUN: %clang_cc1 -analyze -analyzer-checker=core -verify -DSUPPRESSED=1 %s
// RUN: %clang_cc1 -analyze -analyzer-checker=core -analyzer-config avoid-suppressing-null-argument-paths=true -DSUPPRESSED=1 -DNULL_ARGS=1 -verify %s
[analyzer] Suppress bugs whose paths go through the return of a null pointer. This is a heuristic intended to greatly reduce the number of false positives resulting from inlining, particularly inlining of generic, defensive C++ methods that live in header files. The suppression is triggered in the cases where we ask to track where a null pointer came from, and it turns out that the source of the null pointer was an inlined function call. This change brings the number of bug reports in LLVM from ~1500 down to around ~300, a much more manageable number. Yes, some true positives may be hidden as well, but from what I looked at the vast majority of silenced reports are false positives, and many of the true issues found by the analyzer are still reported. I'm hoping to improve this heuristic further by adding some exceptions next week (cases in which a bug should still be reported). llvm-svn: 164449
2012-09-22 09:25:06 +08:00
int opaquePropertyCheck(void *object);
int coin();
[analyzer] New option to not suppress null return paths if an argument is null. Our one basic suppression heuristic is to assume that functions do not usually return NULL. However, when one of the arguments is NULL it is suddenly much more likely that NULL is a valid return value. In this case, we don't suppress the report here, but we do attach /another/ visitor to go find out if this NULL argument also comes from an inlined function's error path. This new behavior, controlled by the 'avoid-suppressing-null-argument-paths' analyzer-config option, is turned off by default. Turning it on produced two false positives and no new true positives when running over LLVM/Clang. This is one of the possible refinements to our suppression heuristics. <rdar://problem/12350829> llvm-svn: 166941
2012-10-30 01:31:59 +08:00
int *getNull() {
return 0;
}
[analyzer] Properly handle the ternary operator in trackNullOrUndefValue 1) Look for the node where the condition expression is live when checking if it is constrained to true or false. 2) Fix a bug in ProgramState::isNull, which was masking the problem. When the expression is not a symbol (,which is the case when it is Unknown) return unconstrained value, instead of value constrained to “false”! (Thankfully other callers of isNull have not been effected by the bug.) llvm-svn: 178684
2013-04-04 03:28:12 +08:00
int* getPtr();
[analyzer] Suppress bugs whose paths go through the return of a null pointer. This is a heuristic intended to greatly reduce the number of false positives resulting from inlining, particularly inlining of generic, defensive C++ methods that live in header files. The suppression is triggered in the cases where we ask to track where a null pointer came from, and it turns out that the source of the null pointer was an inlined function call. This change brings the number of bug reports in LLVM from ~1500 down to around ~300, a much more manageable number. Yes, some true positives may be hidden as well, but from what I looked at the vast majority of silenced reports are false positives, and many of the true issues found by the analyzer are still reported. I'm hoping to improve this heuristic further by adding some exceptions next week (cases in which a bug should still be reported). llvm-svn: 164449
2012-09-22 09:25:06 +08:00
int *dynCastToInt(void *ptr) {
if (opaquePropertyCheck(ptr))
return (int *)ptr;
return 0;
}
int *dynCastOrNull(void *ptr) {
if (!ptr)
return 0;
if (opaquePropertyCheck(ptr))
return (int *)ptr;
return 0;
}
void testDynCast(void *p) {
int *casted = dynCastToInt(p);
*casted = 1;
#ifndef SUPPRESSED
// expected-warning@-2 {{Dereference of null pointer}}
#endif
}
void testDynCastOrNull(void *p) {
int *casted = dynCastOrNull(p);
*casted = 1;
#ifndef SUPPRESSED
// expected-warning@-2 {{Dereference of null pointer}}
#endif
}
void testBranch(void *p) {
int *casted;
// Although the report will be suppressed on one branch, it should still be
// valid on the other.
if (coin()) {
casted = dynCastToInt(p);
} else {
if (p)
return;
casted = (int *)p;
}
*casted = 1; // expected-warning {{Dereference of null pointer}}
}
void testBranchReversed(void *p) {
int *casted;
// Although the report will be suppressed on one branch, it should still be
// valid on the other.
if (coin()) {
if (p)
return;
casted = (int *)p;
} else {
casted = dynCastToInt(p);
}
*casted = 1; // expected-warning {{Dereference of null pointer}}
}
[analyzer] Teach FindLastStoreBRVisitor to understand stores of the same value. Consider this case: int *p = 0; p = getPointerThatMayBeNull(); *p = 1; If we inline 'getPointerThatMayBeNull', we might know that the value of 'p' is NULL, and thus emit a null pointer dereference report. However, we usually want to suppress such warnings as error paths, and we do so by using FindLastStoreBRVisitor to see where the NULL came from. In this case, though, because 'p' was NULL both before and after the assignment, the visitor would decide that the "last store" was the initialization, not the re-assignment. This commit changes FindLastStoreBRVisitor to consider all PostStore nodes that assign to this region. This still won't catches changes made directly by checkers if they re-assign the same value, but it does handle the common case in user-written code and will trigger ReturnVisitor's suppression machinery as expected. <rdar://problem/13299738> llvm-svn: 176201
2013-02-28 02:49:57 +08:00
void testMultipleStore(void *p) {
int *casted = 0;
casted = dynCastToInt(p);
*casted = 1;
#ifndef SUPPRESSED
// expected-warning@-2 {{Dereference of null pointer}}
#endif
}
[analyzer] Make sure that inlined defensive checks work on div by zero. This suppresses a false positive in std::hash_map. Fixes radar://14255587. llvm-svn: 185608
2013-07-04 10:38:06 +08:00
// Test that div by zero does not get suppressed. This is a policy choice.
int retZero() {
return 0;
}
int triggerDivZero () {
int y = retZero();
return 5/y; // expected-warning {{Division by zero}}
}
[analyzer] Suppress bugs whose paths go through the return of a null pointer. This is a heuristic intended to greatly reduce the number of false positives resulting from inlining, particularly inlining of generic, defensive C++ methods that live in header files. The suppression is triggered in the cases where we ask to track where a null pointer came from, and it turns out that the source of the null pointer was an inlined function call. This change brings the number of bug reports in LLVM from ~1500 down to around ~300, a much more manageable number. Yes, some true positives may be hidden as well, but from what I looked at the vast majority of silenced reports are false positives, and many of the true issues found by the analyzer are still reported. I'm hoping to improve this heuristic further by adding some exceptions next week (cases in which a bug should still be reported). llvm-svn: 164449
2012-09-22 09:25:06 +08:00
[analyzer] New option to not suppress null return paths if an argument is null. Our one basic suppression heuristic is to assume that functions do not usually return NULL. However, when one of the arguments is NULL it is suddenly much more likely that NULL is a valid return value. In this case, we don't suppress the report here, but we do attach /another/ visitor to go find out if this NULL argument also comes from an inlined function's error path. This new behavior, controlled by the 'avoid-suppressing-null-argument-paths' analyzer-config option, is turned off by default. Turning it on produced two false positives and no new true positives when running over LLVM/Clang. This is one of the possible refinements to our suppression heuristics. <rdar://problem/12350829> llvm-svn: 166941
2012-10-30 01:31:59 +08:00
// --------------------------
// "Suppression suppression"
// --------------------------
void testDynCastOrNullOfNull() {
// Don't suppress when one of the arguments is NULL.
int *casted = dynCastOrNull(0);
*casted = 1;
#if !SUPPRESSED || NULL_ARGS
// expected-warning@-2 {{Dereference of null pointer}}
#endif
}
void testDynCastOfNull() {
// Don't suppress when one of the arguments is NULL.
int *casted = dynCastToInt(0);
*casted = 1;
#if !SUPPRESSED || NULL_ARGS
// expected-warning@-2 {{Dereference of null pointer}}
#endif
}
int *lookUpInt(int unused) {
if (coin())
return 0;
static int x;
return &x;
}
void testZeroIsNotNull() {
// /Do/ suppress when the argument is 0 (an integer).
int *casted = lookUpInt(0);
*casted = 1;
#ifndef SUPPRESSED
// expected-warning@-2 {{Dereference of null pointer}}
#endif
}
void testTrackNull() {
// /Do/ suppress if the null argument came from another call returning null.
int *casted = dynCastOrNull(getNull());
*casted = 1;
#ifndef SUPPRESSED
// expected-warning@-2 {{Dereference of null pointer}}
#endif
}
void testTrackNullVariable() {
// /Do/ suppress if the null argument came from another call returning null.
int *ptr;
ptr = getNull();
int *casted = dynCastOrNull(ptr);
*casted = 1;
#ifndef SUPPRESSED
// expected-warning@-2 {{Dereference of null pointer}}
#endif
}
[analyzer] Check the stack frame when looking for a var's initialization. FindLastStoreBRVisitor is responsible for finding where a particular region gets its value; if the region is a VarRegion, it's possible that value was assigned at initialization, i.e. at its DeclStmt. However, if a function is called recursively, the same DeclStmt may be evaluated multiple times in multiple stack frames. FindLastStoreBRVisitor was not taking this into account and just picking the first one it saw. <rdar://problem/13787723> llvm-svn: 180997
2013-05-03 13:47:31 +08:00
void inlinedIsDifferent(int inlined) {
int i;
// We were erroneously picking up the inner stack frame's initialization,
// even though the error occurs in the outer stack frame!
int *p = inlined ? &i : getNull();
if (!inlined)
inlinedIsDifferent(1);
*p = 1;
#ifndef SUPPRESSED
// expected-warning@-2 {{Dereference of null pointer}}
#endif
}
void testInlinedIsDifferent() {
// <rdar://problem/13787723>
inlinedIsDifferent(0);
}
[analyzer] New option to not suppress null return paths if an argument is null. Our one basic suppression heuristic is to assume that functions do not usually return NULL. However, when one of the arguments is NULL it is suddenly much more likely that NULL is a valid return value. In this case, we don't suppress the report here, but we do attach /another/ visitor to go find out if this NULL argument also comes from an inlined function's error path. This new behavior, controlled by the 'avoid-suppressing-null-argument-paths' analyzer-config option, is turned off by default. Turning it on produced two false positives and no new true positives when running over LLVM/Clang. This is one of the possible refinements to our suppression heuristics. <rdar://problem/12350829> llvm-svn: 166941
2012-10-30 01:31:59 +08:00
[analyzer] Suppress bugs whose paths go through the return of a null pointer. This is a heuristic intended to greatly reduce the number of false positives resulting from inlining, particularly inlining of generic, defensive C++ methods that live in header files. The suppression is triggered in the cases where we ask to track where a null pointer came from, and it turns out that the source of the null pointer was an inlined function call. This change brings the number of bug reports in LLVM from ~1500 down to around ~300, a much more manageable number. Yes, some true positives may be hidden as well, but from what I looked at the vast majority of silenced reports are false positives, and many of the true issues found by the analyzer are still reported. I'm hoping to improve this heuristic further by adding some exceptions next week (cases in which a bug should still be reported). llvm-svn: 164449
2012-09-22 09:25:06 +08:00
// ---------------------------------------
// FALSE NEGATIVES (over-suppression)
// ---------------------------------------
[analyzer] New option to not suppress null return paths if an argument is null. Our one basic suppression heuristic is to assume that functions do not usually return NULL. However, when one of the arguments is NULL it is suddenly much more likely that NULL is a valid return value. In this case, we don't suppress the report here, but we do attach /another/ visitor to go find out if this NULL argument also comes from an inlined function's error path. This new behavior, controlled by the 'avoid-suppressing-null-argument-paths' analyzer-config option, is turned off by default. Turning it on produced two false positives and no new true positives when running over LLVM/Clang. This is one of the possible refinements to our suppression heuristics. <rdar://problem/12350829> llvm-svn: 166941
2012-10-30 01:31:59 +08:00
void testNoArguments() {
// In this case the function has no branches, and MUST return null.
int *casted = getNull();
*casted = 1;
#ifndef SUPPRESSED
// expected-warning@-2 {{Dereference of null pointer}}
#endif
}
int *getNullIfNonNull(void *input) {
if (input)
return 0;
static int x;
return &x;
}
void testKnownPath(void *input) {
if (!input)
return;
[analyzer] Suppress bugs whose paths go through the return of a null pointer. This is a heuristic intended to greatly reduce the number of false positives resulting from inlining, particularly inlining of generic, defensive C++ methods that live in header files. The suppression is triggered in the cases where we ask to track where a null pointer came from, and it turns out that the source of the null pointer was an inlined function call. This change brings the number of bug reports in LLVM from ~1500 down to around ~300, a much more manageable number. Yes, some true positives may be hidden as well, but from what I looked at the vast majority of silenced reports are false positives, and many of the true issues found by the analyzer are still reported. I'm hoping to improve this heuristic further by adding some exceptions next week (cases in which a bug should still be reported). llvm-svn: 164449
2012-09-22 09:25:06 +08:00
// In this case we have a known value for the argument, and thus the path
// through the function doesn't ever split.
[analyzer] New option to not suppress null return paths if an argument is null. Our one basic suppression heuristic is to assume that functions do not usually return NULL. However, when one of the arguments is NULL it is suddenly much more likely that NULL is a valid return value. In this case, we don't suppress the report here, but we do attach /another/ visitor to go find out if this NULL argument also comes from an inlined function's error path. This new behavior, controlled by the 'avoid-suppressing-null-argument-paths' analyzer-config option, is turned off by default. Turning it on produced two false positives and no new true positives when running over LLVM/Clang. This is one of the possible refinements to our suppression heuristics. <rdar://problem/12350829> llvm-svn: 166941
2012-10-30 01:31:59 +08:00
int *casted = getNullIfNonNull(input);
[analyzer] Suppress bugs whose paths go through the return of a null pointer. This is a heuristic intended to greatly reduce the number of false positives resulting from inlining, particularly inlining of generic, defensive C++ methods that live in header files. The suppression is triggered in the cases where we ask to track where a null pointer came from, and it turns out that the source of the null pointer was an inlined function call. This change brings the number of bug reports in LLVM from ~1500 down to around ~300, a much more manageable number. Yes, some true positives may be hidden as well, but from what I looked at the vast majority of silenced reports are false positives, and many of the true issues found by the analyzer are still reported. I'm hoping to improve this heuristic further by adding some exceptions next week (cases in which a bug should still be reported). llvm-svn: 164449
2012-09-22 09:25:06 +08:00
*casted = 1;
#ifndef SUPPRESSED
// expected-warning@-2 {{Dereference of null pointer}}
#endif
}
[analyzer] New option to not suppress null return paths if an argument is null. Our one basic suppression heuristic is to assume that functions do not usually return NULL. However, when one of the arguments is NULL it is suddenly much more likely that NULL is a valid return value. In this case, we don't suppress the report here, but we do attach /another/ visitor to go find out if this NULL argument also comes from an inlined function's error path. This new behavior, controlled by the 'avoid-suppressing-null-argument-paths' analyzer-config option, is turned off by default. Turning it on produced two false positives and no new true positives when running over LLVM/Clang. This is one of the possible refinements to our suppression heuristics. <rdar://problem/12350829> llvm-svn: 166941
2012-10-30 01:31:59 +08:00
int *alwaysReturnNull(void *input) {
if (opaquePropertyCheck(input))
return 0;
return 0;
}
void testAlwaysReturnNull(void *input) {
[analyzer] Suppress bugs whose paths go through the return of a null pointer. This is a heuristic intended to greatly reduce the number of false positives resulting from inlining, particularly inlining of generic, defensive C++ methods that live in header files. The suppression is triggered in the cases where we ask to track where a null pointer came from, and it turns out that the source of the null pointer was an inlined function call. This change brings the number of bug reports in LLVM from ~1500 down to around ~300, a much more manageable number. Yes, some true positives may be hidden as well, but from what I looked at the vast majority of silenced reports are false positives, and many of the true issues found by the analyzer are still reported. I'm hoping to improve this heuristic further by adding some exceptions next week (cases in which a bug should still be reported). llvm-svn: 164449
2012-09-22 09:25:06 +08:00
// In this case all paths out of the function return 0, but they are all
// dominated by a branch whose condition we don't know!
[analyzer] New option to not suppress null return paths if an argument is null. Our one basic suppression heuristic is to assume that functions do not usually return NULL. However, when one of the arguments is NULL it is suddenly much more likely that NULL is a valid return value. In this case, we don't suppress the report here, but we do attach /another/ visitor to go find out if this NULL argument also comes from an inlined function's error path. This new behavior, controlled by the 'avoid-suppressing-null-argument-paths' analyzer-config option, is turned off by default. Turning it on produced two false positives and no new true positives when running over LLVM/Clang. This is one of the possible refinements to our suppression heuristics. <rdar://problem/12350829> llvm-svn: 166941
2012-10-30 01:31:59 +08:00
int *casted = alwaysReturnNull(input);
[analyzer] Suppress bugs whose paths go through the return of a null pointer. This is a heuristic intended to greatly reduce the number of false positives resulting from inlining, particularly inlining of generic, defensive C++ methods that live in header files. The suppression is triggered in the cases where we ask to track where a null pointer came from, and it turns out that the source of the null pointer was an inlined function call. This change brings the number of bug reports in LLVM from ~1500 down to around ~300, a much more manageable number. Yes, some true positives may be hidden as well, but from what I looked at the vast majority of silenced reports are false positives, and many of the true issues found by the analyzer are still reported. I'm hoping to improve this heuristic further by adding some exceptions next week (cases in which a bug should still be reported). llvm-svn: 164449
2012-09-22 09:25:06 +08:00
*casted = 1;
#ifndef SUPPRESSED
// expected-warning@-2 {{Dereference of null pointer}}
#endif
}
[analyzer] Teach trackNullOrUndef to look through ternary operators Allows the suppression visitors trigger more often. llvm-svn: 177137
2013-03-15 09:15:12 +08:00
int derefArg(int *p) {
return *p;
#ifndef SUPPRESSED
// expected-warning@-2 {{Dereference of null pointer}}
#endif
}
void ternaryArg(char cond) {
static int x;
derefArg(cond ? &x : getNull());
}
[analyzer] BugReporterVisitors: handle the case where a ternary operator is wrapped in a cast. llvm-svn: 177205
2013-03-16 07:34:25 +08:00
int derefArgCast(char *p) {
return *p;
#ifndef SUPPRESSED
// expected-warning@-2 {{Dereference of null pointer}}
#endif
}
void ternaryArgCast(char cond) {
static int x;
derefArgCast((char*)((unsigned)cond ? &x : getNull()));
}
[analyzer] Teach trackNullOrUndef to look through ternary operators Allows the suppression visitors trigger more often. llvm-svn: 177137
2013-03-15 09:15:12 +08:00
int derefAssignment(int *p) {
return *p;
#ifndef SUPPRESSED
// expected-warning@-2 {{Dereference of null pointer}}
#endif
}
[analyzer] Properly handle the ternary operator in trackNullOrUndefValue 1) Look for the node where the condition expression is live when checking if it is constrained to true or false. 2) Fix a bug in ProgramState::isNull, which was masking the problem. When the expression is not a symbol (,which is the case when it is Unknown) return unconstrained value, instead of value constrained to “false”! (Thankfully other callers of isNull have not been effected by the bug.) llvm-svn: 178684
2013-04-04 03:28:12 +08:00
[analyzer] Teach trackNullOrUndef to look through ternary operators Allows the suppression visitors trigger more often. llvm-svn: 177137
2013-03-15 09:15:12 +08:00
void ternaryAssignment(char cond) {
static int x;
[analyzer] Properly handle the ternary operator in trackNullOrUndefValue 1) Look for the node where the condition expression is live when checking if it is constrained to true or false. 2) Fix a bug in ProgramState::isNull, which was masking the problem. When the expression is not a symbol (,which is the case when it is Unknown) return unconstrained value, instead of value constrained to “false”! (Thankfully other callers of isNull have not been effected by the bug.) llvm-svn: 178684
2013-04-04 03:28:12 +08:00
int *p = cond ? getNull() : getPtr();
[analyzer] Teach trackNullOrUndef to look through ternary operators Allows the suppression visitors trigger more often. llvm-svn: 177137
2013-03-15 09:15:12 +08:00
derefAssignment(p);
}
int *retNull(char cond) {
static int x;
return cond ? &x : getNull();
}
int ternaryRetNull(char cond) {
int *p = retNull(cond);
return *p;
#ifndef SUPPRESSED
// expected-warning@-2 {{Dereference of null pointer}}
#endif
}
[analyzer] make peelOffOuterExpr in BugReporterVisitors recursively peel off select Exprs llvm-svn: 178685
2013-04-04 03:28:15 +08:00
// Test suppression of nested conditional operators.
int testConditionalOperatorSuppress(int x) {
return *(x ? getNull() : getPtr());
#ifndef SUPPRESSED
// expected-warning@-2 {{Dereference of null pointer}}
#endif
}
int testNestedConditionalOperatorSuppress(int x) {
return *(x ? (x ? getNull() : getPtr()) : getPtr());
#ifndef SUPPRESSED
// expected-warning@-2 {{Dereference of null pointer}}
#endif
}
int testConditionalOperator(int x) {
return *(x ? 0 : getPtr()); // expected-warning {{Dereference of null pointer}}
}
int testNestedConditionalOperator(int x) {
return *(x ? (x ? 0 : getPtr()) : getPtr()); // expected-warning {{Dereference of null pointer}}
}
int testConditionalOperatorSuppressFloatCond(float x) {
[analyzer] Allow tracknullOrUndef look through the ternary operator even when condition is unknown Improvement of r178684 and r178685. Jordan has pointed out that I should not rely on the value of the condition to know which expression branch has been taken. It will not work in cases the branch condition is an unknown value (ex: we do not track the constraints for floats). The better way of doing this would be to find out if the current node is the right or left successor of the node that has the ternary operator as a terminator (which is how this is done in other places, like ConditionBRVisitor). llvm-svn: 178701
2013-04-04 05:34:12 +08:00
return *(x ? getNull() : getPtr());
#ifndef SUPPRESSED
// expected-warning@-2 {{Dereference of null pointer}}
#endif
[analyzer] make peelOffOuterExpr in BugReporterVisitors recursively peel off select Exprs llvm-svn: 178685
2013-04-04 03:28:15 +08:00
}
[analyzer] Teach trackNullOrUndef to look through ternary operators Allows the suppression visitors trigger more often. llvm-svn: 177137
2013-03-15 09:15:12 +08:00