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/diagnostics/undef-value-param.c

66 lines
2.3 KiB
C
Raw Normal View History

Reland 4: [analyzer] NFC: Update test infrastructure to support multiple constraint managers Summary: Replace calls to %clang/%clang_cc1 with %clang_analyze_cc1 when invoking static analyzer, and perform runtime substitution to select the appropriate constraint manager, per D28952. Reviewers: xazax.hun, NoQ, zaks.anna, dcoughlin Subscribers: mgorny, rgov, mikhail.ramalho, a.sidorin, cfe-commits Differential Revision: https://reviews.llvm.org/D30373 llvm-svn: 296895
2017-03-04 02:02:02 +08:00
// RUN: %clang_analyze_cc1 -analyzer-checker=core -analyzer-output=text -verify %s
[analyzer] [NFC] Remove unused Extensive diagnostic setting, Rename AlternateExtensive to Extensive. In 2013, five years ago, we have switched to AlternateExtensive diagnostics by default, and Extensive was available under unused, undocumented flag. This change remove the flag, renames the Alternate diagnostic to Extensive (as it's no longer Alternate), and ports the test. Differential Revision: https://reviews.llvm.org/D47670 llvm-svn: 334524
2018-06-13 03:07:41 +08:00
// RUN: %clang_analyze_cc1 -analyzer-checker=core -analyzer-output=plist-multi-file %s -o %t.plist
[analyzer] [NFC] Reverse the argument order for "diff" in tests The current argument order has "expected" and "actual" the wrong way around, so that the diff shows the change from expected to actual, not from actual to expected. Namely, if the expected diagnostics contains the string "foo", but the analyzer emits "bar", we really want to see: ``` - foo + bar ``` not ``` - bar + foo ``` since adapting to most changes would require applying that diff to the expected output. Differential Revision: https://reviews.llvm.org/D56340 llvm-svn: 350866
2019-01-11 02:15:44 +08:00
// RUN: cat %t.plist | %diff_plist %S/Inputs/expected-plists/undef-value-param.c.plist -
[analyzer] Improved diagnostic pruning for calls initializing values. This heuristic addresses the case when a pointer (or ref) is passed to a function, which initializes the variable (or sets it to something other than '0'). On the branch where the inlined function does not set the value, we report use of undefined value (or NULL pointer dereference). The access happens in the caller and the path through the callee would get pruned away with regular path pruning. To solve this issue, we previously disabled diagnostic pruning completely on undefined and null pointer dereference checks, which entailed very verbose diagnostics in most cases. Furthermore, not all of the undef value checks had the diagnostic pruning disabled. This patch implements the following heuristic: if we pass a pointer (or ref) to the region (on which the error is reported) into a function and it's value is either undef or 'NULL' (and is a pointer), do not prune the function. llvm-svn: 162863
2012-08-30 05:22:37 +08:00
void foo_irrelevant(int c) {
if (c)
return;
c++;
return;
}
[analyzer] Fixup 162863. Thanks Jordan. llvm-svn: 162875
2012-08-30 07:23:39 +08:00
void foo(int c, int *x) {
[analyzer] Improved diagnostic pruning for calls initializing values. This heuristic addresses the case when a pointer (or ref) is passed to a function, which initializes the variable (or sets it to something other than '0'). On the branch where the inlined function does not set the value, we report use of undefined value (or NULL pointer dereference). The access happens in the caller and the path through the callee would get pruned away with regular path pruning. To solve this issue, we previously disabled diagnostic pruning completely on undefined and null pointer dereference checks, which entailed very verbose diagnostics in most cases. Furthermore, not all of the undef value checks had the diagnostic pruning disabled. This patch implements the following heuristic: if we pass a pointer (or ref) to the region (on which the error is reported) into a function and it's value is either undef or 'NULL' (and is a pointer), do not prune the function. llvm-svn: 162863
2012-08-30 05:22:37 +08:00
if (c)
//expected-note@-1{{Assuming 'c' is not equal to 0}}
//expected-note@-2{{Taking true branch}}
[analyzer] mark returns of functions where the region passed as parameter was not initialized In the wild, many cases of null pointer dereference, or uninitialized value read occur because the value was meant to be initialized by the inlined function, but did not, most often due to error condition in the inlined function. This change highlights the return branch taken by the inlined function, in order to help user understand the error report and see why the value was uninitialized. rdar://36287652 Differential Revision: https://reviews.llvm.org/D41848 llvm-svn: 325976
2018-02-24 07:26:56 +08:00
return; // expected-note{{Returning without writing to '*x'}}
[analyzer] Improved diagnostic pruning for calls initializing values. This heuristic addresses the case when a pointer (or ref) is passed to a function, which initializes the variable (or sets it to something other than '0'). On the branch where the inlined function does not set the value, we report use of undefined value (or NULL pointer dereference). The access happens in the caller and the path through the callee would get pruned away with regular path pruning. To solve this issue, we previously disabled diagnostic pruning completely on undefined and null pointer dereference checks, which entailed very verbose diagnostics in most cases. Furthermore, not all of the undef value checks had the diagnostic pruning disabled. This patch implements the following heuristic: if we pass a pointer (or ref) to the region (on which the error is reported) into a function and it's value is either undef or 'NULL' (and is a pointer), do not prune the function. llvm-svn: 162863
2012-08-30 05:22:37 +08:00
*x = 5;
}
int use(int c) {
[analyzer] Use 'MemRegion::printPretty()' instead of assuming the region is a VarRegion. Fixes PR15358 and <rdar://problem/13295437>. Along the way, shorten path diagnostics that say "Variable 'x'" to just be "'x'". By the context, it is obvious that we have a variable, and so this just consumes text space. llvm-svn: 176115
2013-02-27 03:44:38 +08:00
int xx; //expected-note {{'xx' declared without an initial value}}
[analyzer] Improved diagnostic pruning for calls initializing values. This heuristic addresses the case when a pointer (or ref) is passed to a function, which initializes the variable (or sets it to something other than '0'). On the branch where the inlined function does not set the value, we report use of undefined value (or NULL pointer dereference). The access happens in the caller and the path through the callee would get pruned away with regular path pruning. To solve this issue, we previously disabled diagnostic pruning completely on undefined and null pointer dereference checks, which entailed very verbose diagnostics in most cases. Furthermore, not all of the undef value checks had the diagnostic pruning disabled. This patch implements the following heuristic: if we pass a pointer (or ref) to the region (on which the error is reported) into a function and it's value is either undef or 'NULL' (and is a pointer), do not prune the function. llvm-svn: 162863
2012-08-30 05:22:37 +08:00
int *y = &xx;
[analyzer] Fixup 162863. Thanks Jordan. llvm-svn: 162875
2012-08-30 07:23:39 +08:00
foo (c, y);
[analyzer] Improved diagnostic pruning for calls initializing values. This heuristic addresses the case when a pointer (or ref) is passed to a function, which initializes the variable (or sets it to something other than '0'). On the branch where the inlined function does not set the value, we report use of undefined value (or NULL pointer dereference). The access happens in the caller and the path through the callee would get pruned away with regular path pruning. To solve this issue, we previously disabled diagnostic pruning completely on undefined and null pointer dereference checks, which entailed very verbose diagnostics in most cases. Furthermore, not all of the undef value checks had the diagnostic pruning disabled. This patch implements the following heuristic: if we pass a pointer (or ref) to the region (on which the error is reported) into a function and it's value is either undef or 'NULL' (and is a pointer), do not prune the function. llvm-svn: 162863
2012-08-30 05:22:37 +08:00
//expected-note@-1{{Calling 'foo'}}
//expected-note@-2{{Returning from 'foo'}}
foo_irrelevant(c);
return xx+3; //expected-warning{{The left operand of '+' is a garbage value}}
//expected-note@-1{{The left operand of '+' is a garbage value}}
}
[analyzer] Teach UndefOrNullArgVisitor to track parent regions. llvm-svn: 163748
2012-09-13 06:57:30 +08:00
void initArray(int x, double XYZ[3]) {
if (x <= 0) //expected-note {{Taking true branch}}
//expected-note@-1 {{Assuming 'x' is <= 0}}
return;
XYZ[0] = 1;
XYZ[1] = 1;
XYZ[2] = 1;
}
int testPassingParentRegionArray(int x) {
double XYZ[3];
initArray(x, XYZ); //expected-note {{Calling 'initArray'}}
//expected-note@-1 {{Returning from 'initArray'}}
return 1 * XYZ[1]; //expected-warning {{The right operand of '*' is a garbage value}}
//expected-note@-1 {{The right operand of '*' is a garbage value}}
}
double *getValidPtr();
struct WithFields {
double *f1;
};
void initStruct(int x, struct WithFields *X) {
if (x <= 0) //expected-note {{Taking true branch}}
//expected-note@-1 {{Assuming 'x' is <= 0}}
[analyzer] mark returns of functions where the region passed as parameter was not initialized In the wild, many cases of null pointer dereference, or uninitialized value read occur because the value was meant to be initialized by the inlined function, but did not, most often due to error condition in the inlined function. This change highlights the return branch taken by the inlined function, in order to help user understand the error report and see why the value was uninitialized. rdar://36287652 Differential Revision: https://reviews.llvm.org/D41848 llvm-svn: 325976
2018-02-24 07:26:56 +08:00
return; //expected-note{{Returning without writing to 'X->f1'}}
[analyzer] Teach UndefOrNullArgVisitor to track parent regions. llvm-svn: 163748
2012-09-13 06:57:30 +08:00
X->f1 = getValidPtr();
}
double testPassingParentRegionStruct(int x) {
struct WithFields st;
[analyzer] tracking stores/constraints now works for ObjC ivars or struct fields. This required more changes than I originally expected: - ObjCIvarRegion implements "canPrintPretty" et al - DereferenceChecker indicates the null pointer source is an ivar - bugreporter::trackNullOrUndefValue() uses an alternate algorithm to compute the location region to track by scouring the ExplodedGraph. This allows us to get the actual MemRegion for variables, ivars, fields, etc. We only hand construct a VarRegion for C++ references. - ExplodedGraph no longer drops nodes for expressions that are marked 'lvalue'. This is to facilitate the logic in the previous bullet. This may lead to a slight increase in size in the ExplodedGraph, which I have not measured, but it is likely not to be a big deal. I have validated each of the changed plist output. Fixes <rdar://problem/12114812> llvm-svn: 175988
2013-02-24 15:21:01 +08:00
st.f1 = 0; // expected-note {{Null pointer value stored to 'st.f1'}}
[analyzer] Teach UndefOrNullArgVisitor to track parent regions. llvm-svn: 163748
2012-09-13 06:57:30 +08:00
initStruct(x, &st); //expected-note {{Calling 'initStruct'}}
//expected-note@-1 {{Returning from 'initStruct'}}
return (*st.f1); //expected-warning {{Dereference of null pointer}}
//expected-note@-1{{Dereference of null pointer (loaded from field 'f1')}}
}