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.
* Avoid some additional memleakOnRealloc false positives
checkReallocUsage() already contains code to suppress the
`p = realloc(p, size)` error message when the pointer has been
previously copied from another variable (hence there is an additional
copy of the original pointer value) within the same function, as in
the added realloc21() test case.
Extend this so that `p = *pp` and `p = ptr->foo` are also recognized
as copies from another variable with the same original pointer value,
as in the added realloc22() and realloc23() test cases.
* Rewrite as a single findmatch() expression
* use range loops
* removed redundant string initializations
* use nullptr
* use proper boolean false
* removed unnecessary continue from end of loop
* removed unnecessary c_str() usage
* use emplace_back()
* removed redundant void arguments
There seems to be no reason for stopping checking the scope if a call to
free() is seen (or fclose() or realloc()), so just continue checking.
Also, if there are multiple arguments, check all, perhaps there are more
memory leaks to warn about.
Use the AST a little bit more to improve the check. In order to do so,
rewrite the check to work from the outer function first and then check
the arguments, instead of the other way around.
It also fixes Trac ticket #9252, no warning is now given for
void* malloc1() {
return(malloc1(1));
}
This FP seems to be common in daca results.
It also makes it possible to improve handling of casts, for example
cppcheck now warns about
void f() {
strcpy(a, (void*) strdup(p));
}
But not for
char* f() {
char* ret = (char*)strcpy(malloc(10), "abc");
return ret;
}
These FP/FN were introduced when the check was switched to use the
simplified token list.
This fixes false positives from daca@home where freopen is used to
reopen a standard stream. There is no longer a warning for
void f() {
assert(freopen("/dev/null", "r", stdin));
}
* Use library for memleak checks
Change memleakOnRealloc and leakReturnValNotUsed to use library
configuration instead of hardcoding "realloc".
In order to do so, some care needs to be taken when matching for a
reallocation function, since it can no longer be assumed that the input
to be allocated is the first argument of the function. This complicates
getReallocationType() and checkReallocUsage() but is necessary in order
to handle for example freopen() properly.
Also, refactor memleakOnRealloc check to reduce duplicated code when
checking "a" and "*a". When doing so, extending the check to look for
arbitrary number of "*" can be done for free (just change an if
statement to a while statement). Most likely, this is an unusual case in
real world code.
* Remove redundant whitespace in Token::Match()
* Run on simplified checks
* Fix cppcheck warning
* Allow to configure realloc like functions
* memleakonrealloc: Bring back tests.
The old memleak checker was removed, and the tests for it was removed in
commit 9765a2dfab. This also removed the
tests for memleakOnRealloc. Bring back those tests, somewhat modified
since the checker no longer checks for memory leaks.
* Add realloc to mem leak check
* Add tests of realloc buffer size
* Configure realloc functions
* Add test of freopen
* Allow to configure which element is realloc argument
* Fix wrong close in test
cppcheck now warns for this
* Update manual
* Update docs
* Rename alloc/dalloc/realloc functions
Naming the member function realloc caused problems on appveyor. Rename
the alloc and dealloc functions as well for consistency.
* Change comparisson order
* Remove variable and use function call directly
* Create temporary variable to simplify
* Throw mismatchError on mismatching allocation/reallocation
* Refactor to separate function
* Fix potential nullptr dereference
As pointed out by cppcheck.
Building with enhanced clang warnings indicated a large number of
instances with the warning:
`warning: zero as null pointer constant`
Recommended practice in C++11 is to use `nullptr` as value for
a NULL or empty pointer value. All instances where this warning
was encountered were corrected in this commit.
Where warning was encountered in dependency code (i.e. external library)
no chnages were made. Patching will be offered upstream.
Oliver Stöneberg
Rikard Falkeborn
chrchr-github
Paul Fultz II
Daniel Marjamäki
keinflue
PKEuS
PKEuS
John Marshall
Scott Furry
orbitcowboy
IOBYTE