Repository navigation
Commit e772b35
Fix #15005: FP uninitdata with compound assignment or increment (#8822)
isVariableUsage() currently returns nullptr for the lhs of assignment
operators, because unless it's a pointer that gets dereferenced, it is
just getting overwritten and its potentially uninitialized value is not
read. I extend this idea to compound assignment and increment/decrement
operators.
While working on this, I found some issues with CTU analysis.
```
valueFlowUninit("void increment(int& i) { ++i; }\n" // #6475
"int f() {\n"
" int n;\n"
" increment(n);\n"
" return n;\n"
"}\n");
ASSERT_EQUALS("[test.cpp:4:15] -> [test.cpp:1:28]: (warning) Uninitialized variable: i [uninitvar]\n", errout_str());
```
this test only works because of the false positive "usage" from the
increment operator. For example, this test breaks if we use regular
assignment because of the current code properly handling "="
this code
```
void increment(int& i) { i = i + 1; }
int f() {
int n;
increment(n);
return n;
}
```
misses the ctu error, and only throws
```
Checking examples/ctu3.cpp ...
examples/ctu3.cpp:1:30: warning: Uninitialized variable: i [uninitvar]
void increment(int& i) { i = i + 1; }
^
examples/ctu3.cpp:4:15: note: Calling function 'increment', 1st argument 'n' value is <Uninit>
increment(n);
^
examples/ctu3.cpp:1:30: note: Uninitialized variable: i
void increment(int& i) { i = i + 1; }
^
```
I think that the problem has to do with
```
// NOLINTNEXTLINE(readability-non-const-parameter) - used as callback so we need to preserve the signature
static bool isVariableUsage(const Settings &settings, const Token *vartok, MathLib::bigint *value)
{
(void)value;
return !!CheckUninitVarImpl::isVariableUsage(vartok, settings.library, true, CheckUninitVarImpl::Alloc::ARRAY);
}
```
the hardcoded pointer=true and alloc=ARRAY assignments tell
isVariableUsage to return nullptr if it i isn't dereferenced, which it
isn't. If we are going to hardcode these values to be this conservative
then this test should fail because it currently only passes due to the
FP bug I want to fix. I currently have a workaround where I use
vartok->variable() to determine whether something is actually a
pointer/array.
Maybe there can be another PR where we rework the ctu/uninitvar
connection. Notably since I don't touch the "=" branch of the code the
false negative I mentioned above remains unfixed. Let me know if I
should apply my vartok workaround to that code in this PR, if it should
be another PR, or if its just the wrong idea overall.
---------
Co-authored-by: Daniel Marjamäki <daniel.marjamaki@gmail.com>1 parent 8f0dd64 commit e772b35
2 files changed
Lines changed: 76 additions & 1 deletion
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
834 | 834 | | |
835 | 835 | | |
836 | 836 | | |
837 | | - | |
| 837 | + | |
838 | 838 | | |
839 | 839 | | |
840 | 840 | | |
| |||
1295 | 1295 | | |
1296 | 1296 | | |
1297 | 1297 | | |
| 1298 | + | |
| 1299 | + | |
| 1300 | + | |
| 1301 | + | |
| 1302 | + | |
| 1303 | + | |
| 1304 | + | |
| 1305 | + | |
| 1306 | + | |
| 1307 | + | |
| 1308 | + | |
| 1309 | + | |
| 1310 | + | |
1298 | 1311 | | |
1299 | 1312 | | |
1300 | 1313 | | |
| |||
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
2202 | 2202 | | |
2203 | 2203 | | |
2204 | 2204 | | |
| 2205 | + | |
| 2206 | + | |
| 2207 | + | |
| 2208 | + | |
| 2209 | + | |
| 2210 | + | |
| 2211 | + | |
| 2212 | + | |
| 2213 | + | |
| 2214 | + | |
| 2215 | + | |
| 2216 | + | |
| 2217 | + | |
| 2218 | + | |
| 2219 | + | |
| 2220 | + | |
| 2221 | + | |
| 2222 | + | |
| 2223 | + | |
| 2224 | + | |
| 2225 | + | |
| 2226 | + | |
| 2227 | + | |
| 2228 | + | |
| 2229 | + | |
| 2230 | + | |
| 2231 | + | |
| 2232 | + | |
| 2233 | + | |
| 2234 | + | |
| 2235 | + | |
| 2236 | + | |
| 2237 | + | |
| 2238 | + | |
| 2239 | + | |
| 2240 | + | |
| 2241 | + | |
| 2242 | + | |
| 2243 | + | |
| 2244 | + | |
| 2245 | + | |
| 2246 | + | |
| 2247 | + | |
| 2248 | + | |
| 2249 | + | |
| 2250 | + | |
| 2251 | + | |
| 2252 | + | |
| 2253 | + | |
| 2254 | + | |
| 2255 | + | |
| 2256 | + | |
2205 | 2257 | | |
2206 | 2258 | | |
2207 | 2259 | | |
| |||
8177 | 8229 | | |
8178 | 8230 | | |
8179 | 8231 | | |
| 8232 | + | |
| 8233 | + | |
| 8234 | + | |
| 8235 | + | |
| 8236 | + | |
| 8237 | + | |
| 8238 | + | |
| 8239 | + | |
| 8240 | + | |
| 8241 | + | |
8180 | 8242 | | |
8181 | 8243 | | |
8182 | 8244 | | |
| |||
0 commit comments