Added new suppress comments:
- `cppcheck-suppress-begin` and `cppcheck-suppress-end` to remove blocks
of suppression
- `cppcheck-suppress-file` to remove suppression at file level
The suppressions do not interfere with each others. For example, all the
suppressions are matched in the following code:
```c
// cppcheck-suppress-file uninitvar
void f() {
int a;
// cppcheck-suppress-begin uninitvar
// cppcheck-suppress uninitvar
a++;
// cppcheck-suppress-end uninitvar
}
```
Tickets:
https://trac.cppcheck.net/ticket/11902https://trac.cppcheck.net/ticket/8528
Currently the `AddonInfo` is generated and discarded on each addon
invocation. This leads to an unnecessary process invocation for each
addon on each file.
Also if an addon is completely broken we will still perform the whole
analysis only for it to be failed at the end so we should bail out early
if we know it doesn't work at all.
I got error messages while building `cppcheck 2.12.0` for RISC-V Arch
Linux:
```
Testing Complete
Number of tests: 4420
Number of todos: 331
Tests failed: 2
/usr/src/debug/cppcheck/cppcheck/test/testcondition.cpp:4501(TestCondition::alwaysTrue): Assertion failed.
Expected:
[test.cpp:6]: (style) Condition 'o[1]=='\0'' is always false\n
Actual:
[test.cpp:4] -> [test.cpp:6]: (style) Condition 'o[1]=='\0'' is always false\n
_____
/usr/src/debug/cppcheck/cppcheck/test/testcondition.cpp:5014(TestCondition::alwaysTrueContainer): Assertion failed.
Expected:
[test.cpp:5]: (style) Condition 'buffer.back()=='\0'' is always false\n
Actual:
[test.cpp:3] -> [test.cpp:5]: (style) Condition 'buffer.back()=='\0'' is always false\n
```
I found out the reason is that the testcases were designed for
x86/x86_64 or other `signed char` platforms (i.e. default character type
is `signed char` ), whereareas RISC-V is an `unsigned char` platform,
which causes different behavior in
`lib/valueflow.cpp:valueFlowImpossibleValues`. I'm not sure whether this
error leads from a functional bug, so if you have a better approach to
fix it, please let me know.
Maybe you could reproduce this error on x86_64 platform by setting
`defaultSign = 'u';` in `Platform::set(Type t)`.
The name was misleading as it was actually a `long long` and also if we
ever move to an (optional) 128-bit value it wouldn't even less fitting.
We should name it to match our alias type.
This is a step onto leveraging the `ThreadExecutor` implementation for
`ProcessExecutor` which is a follow-up to #4870. We need to have the
proper test coverage and the existing implementations working as
expected before we move to the shared code.
Fixes:
- added `--showtime=` tests for all executor implementations
- only print `--showtime=summary` once at the end
- prevents `--showtime=` by multiple threads to be written at the same
time - essentially breaking the output
- reset the timer results before each test
- deprecated `top5` in favor of `top5_file`
- fixed printing for all executors except `ProcessExecutor`
This is in preparation of avoiding accessing `std::cout` directly as
well as streamlining and improving the logging during the settings
parsing. There are no functional changes yet.
Based on #4701, #5418
A helper function for the `isdigit()` test should be introduced on the
simplecpp side.
Co-authored-by: gerboengels <github@gerbo.org>
We were calling several interface functions through their inherited
classes instead of using the base classes requiring us to add `friend`
declarations to make the implementations accessible. This adjusts
several of those cases.
This makes the code much more readable. It also makes it less prone to
errors because we do not need to specify the length of the string to
match and the returnvalue is clear.
The code with the bad returnvalue check was never executed and I added a
test to show that.
Windows XP Pro x64 was released on April 25, 2005 and consumer
processors supporting x86-64 have been around almost as long. Although
there are still 32-bit Windows images available there is not much of a
point maintaining support for these. We also never did any x86 builds
for non-Windows platforms in CI so we don't even know if we work on
those. You might still be able to build 32-bit binaries via CMake.
This used to be one of the longest running jobs because of the slow
setup and linking. Now it will take only ~2 minutes if everything is
cached with half the time taken up by the tests.
Encountered while investigating https://trac.cppcheck.net/ticket/11708.
This has been like this since the introduction of `internalError` in
b6bcdf2936 (almost ten years ago to the
day). Logging internal errors which bail out(!) of the analysis simply
to `std::cout` for them possibly never to be seen (and also not affected
the exitcode) is pretty bad IMO. They should always be visible.
I also removed the filename from the message as it is already available
(and thus redundant) and its existence should be defined by the
template.
Scanning the `cli` folder with `DISABLE_VALUEFLOW=1` `Tokenizer::dump()`
will consume almost 25% of the total Ir count when an addon is
specified. This is mainly caused by the usage of `std::ostream`.
Encountered while profiling #4958.
Still ran into an assert failure in `Tokenizer::hasIfdef()`, since some
checks assume that the tokenizer is always present. Seems like
clangimport is yet another rogue under-tested feature...
Commit 73251544a ("Fix #11842 FN constParameterPointer with library
function (#5257)") most likely introduced a regression for (C) function
pointers passed to functions provided by the standard library that
cppcheck has knowledge about.
This was introduced in #5279. We were transferring the terminating `\0`
via the pipe and also added another one in the parsing. As we are now
directly writing into a `std::string` these extra characters will now
show up in it. So just get rid of them.
This adds a new checker to check for pointer to bool conversions that
are always known. I removed the previous knownConditionTrueFalse checks
since this was too noisy.
There was no need for the `Tokenizer` parameter to be a pointer as it
could never be `nullptr` and was also dereferenced without checking
first.
As a reference to the `Settings` was already available via the
`Tokenizer` there was no need to pass it separately. In the production
code there will only be one instance of it but in the tests we could
have accidentally passed a different one.
Both are bugprone since they just take the next parameter which doesn't
start with `-`.
Also `--template` has not been documented since
17842394c0 back in 2011(!). And
`--template-location` has never been documented since its induction in
f058d9ad08. That's also why we can have a
short deprecation period.
It was also used inconsistently and seemed to imply there is some
special handling which wasn't the case. It was just an alias for
`std::to_string()` for non-`double` types. So there was no need for it.
---------
Co-authored-by: Robert Reif <reif@earthlink.net>
In cppcheck 2.11.1 (macOS), using `-j 0` actually causes cppcheck to do
nothing–it stalls indefinitely.
I could only find one place where `mSettings.jobs` was validated against
> 0 and it's simply an assert, so you wouldn't hit it in a release
build.
- Require -j >= 1 ✅
- Cap -j at 1024, not 10000 ✅ (I don't even know what would happen if
you created 10,000 threads, but nothing good; likely exhaust virtual
memory or grind the process to a halt). 1024 is still obscene but there
may be some hypercomputers out there that have that many logical cores.
Oliver Stöneberg
chrchr-github
orbitcowboy
Daniel Marjamäki
Johan Bertrand
moui0
Paul Fultz II
Tomasz Edward Posluszny
Valentin Batz
Anton Lindqvist
Ryan M. Lederman