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`.
The template parameter is confusing simplifyUsing: it does not compute
properly the scope, and we end up replace "type" in "to_string" with
"void", then later "void" is removed and we have an internal error.
* Fix some false positive in loop forward analysis
In cases like:
```
bool b();
void f()
{
int val[50];
int i, sum=0;
for (i = 1; b() && i < 50; i++)
sum += val[i];
for (; i < 50; i++)
sum -= val[i];
}
```
The forward analysis assumed the second loop was entered, and we ended
up with false positive in it:
`Array 'val[50]' accessed at index 50, which is out of bounds`
* Fix style
Daniel Marjamäki
Paul
Ken-Patrick Lehrmann
Rikard Falkeborn
orbitcowboy
Jens Yllman
firewave
Simon Martin