This fixes issues (at least false positives) in code using them.
For instance:
```
unsigned compute(unsigned long long a) {
unsigned num = 0;
while (a > 0xFFFFFFFF) {
a >>= 32;
num += 32;
}
if (a > 0xFFFF) {
a >>= 16;
num += 16;
}
if (a > 0xFF) {
num += 8;
}
return num;
}
```
would give false positive:
```
cppcheck --enable=style sl3.cpp
Checking sl3.cpp ...
sl3.cpp:11:11: style: Condition 'a>0xFF' is always false [knownConditionTrueFalse]
if (a > 0xFF) {
^
sl3.cpp:3:14: note: Assuming that condition 'a>0xFFFFFFFF' is not redundant
while (a > 0xFFFFFFFF) {
^
sl3.cpp:11:11: note: Condition 'a>0xFF' is always false
if (a > 0xFF) {
^
```
The loop only checks astoperand1 and astoperand2. Simplify the condition
to loop over these instead of using a stack. Also, add a testcase for
when astoperand2 is negative.
Typically with
```
int F(int *f);
void F2(int *a, int *b) {
int c = *a;
F(a); // modifies *a
if (b && c != *a) {}
}
```
we would get the following FP:
```
[test.cpp:3] -> [test.cpp:5]: (style) The comparison 'c != *a' is always false because 'c' and '*a' represent the same value.\n
```
I guess it boils down to isSameExpression only checking that the
expression is the same (in the above case, "*a" and "*a" are indeed the
same), but there's not real check on the values.
So the patch here is a bit hackish, and we still have false negatives in
cases with dereferenced pointers.
cppcheck behaved differently if sizeof was to the left or right of the
comparison. In order to fix this, we cannot break the while loop until
all operands have been processed.
When the first argument was (void *)(1), at the start of the second
iteration, arg was pointing to the "1", which caused problems for
nextArgument(), which saw the ")" as the next token and returned
nullptr, signalling that there are no more arguments.
Instead, save the first token in the argument, which makes
nextArgument() do the right thing.
Skip scopes with lambdas (similar to how checkleakautovar does). In
order to fix this when the lambda is inside a for loop, make
hasInlineOrLambdaFunction() recursive. This should be what all existing
users want.
In some cases, the condition of the ternary operator is assigned a known
value after the two possible results, and in such cases, we would not
take the opportunity to assign a value to the ternary operator (and to
the other parents in the ast).
This patch adds this capability.
Teaching cppcheck about `BOOST_THROW_EXCEPTION` and
`boost::throw_exception`, and using noreturn information from libraries
in value flow.
This fixes false positive nullPointerRedundantCheck with the following
code:
```
void throwexception(int * buf)
{
if (!buf)
boost::throw_exception(std::bad_alloc());
*buf = 0;
}
```
* 9768: Fix ast with throw in the middle of return
```
int f(bool x)
{
return x ? 0 : throw 0;
}
```
The `throw` part was not included in the ast, leading to an invalid
ternary operator.
* 8526: Fix ast construction for ternary operator
This tries to decide a bit more properly when ':' can be part of a
ternary operator. More precisely, there are some times when we want to
delay the construction of the ast for ':', so that it is place
accordingly to the matching '?'.
Typically, this fixes an issue with
`return val < 0 ? throw 1 : val;`,
where the ast for ':' would be constructed during as part of the
`throw`, and the ast for `?` would be invalid.
This patch is a bit of a hardcode, stating that we don't expect ':'
inside a throw, unless there is a complete ternary operator in there
(there can't be a range based for loop, a case in a switch). When we
reach ':', we know we are and the end of the `throw`.
This tries to decide a bit more properly when ':' can be part of a
ternary operator. More precisely, there are some times when we want to
delay the construction of the ast for ':', so that it is place
accordingly to the matching '?'.
Typically, this fixes an issue with
`return val < 0 ? throw 1 : val;`,
where the ast for ':' would be constructed during as part of the
`throw`, and the ast for `?` would be invalid.
This patch is a bit of a hardcode, stating that we don't expect ':'
inside a throw, unless there is a complete ternary operator in there
(there can't be a range based for loop, a case in a switch). When we
reach ':', we know we are and the end of the `throw`.
Ken-Patrick LEHRMANN
Daniel Marjamäki
Paul
Rikard Falkeborn
Georgy Komarov
Ken-Patrick Lehrmann
orbitcowboy
Jens Yllman
firewave