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.
This provides a report of the top incomplete variables reported by the
ValueFlow analysis. This is based on the implementation of the existing
`--check-library` reports.
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.
This fixes a crash with following error:
```
Traceback (most recent call last):
File "/usr/local/share/Cppcheck/addons/runaddon.py", line 8, in <module>
runpy.run_path(addon, run_name='__main__')
File "<frozen runpy>", line 291, in run_path
File "<frozen runpy>", line 98, in _run_module_code
File "<frozen runpy>", line 88, in _run_code
File "/usr/local/share/Cppcheck/addons/misra.py", line 4737, in <module>
main()
File "/usr/local/share/Cppcheck/addons/misra.py", line 4679, in main
checker.parseDump(item)
File "/usr/local/share/Cppcheck/addons/misra.py", line 4335, in parseDump
self.executeCheck(902, self.misra_9_2, cfg)
File "/usr/local/share/Cppcheck/addons/misra.py", line 4246, in executeCheck
check_function(*args)
File "/usr/local/share/Cppcheck/addons/misra.py", line 2104, in misra_9_2
misra_9.misra_9_x(self, data, 902)
File "/usr/local/share/Cppcheck/addons/misra_9.py", line 414, in misra_9_x
parser.parseInitializer(ed, eq.astOperand2)
File "/usr/local/share/Cppcheck/addons/misra_9.py", line 320, in parseInitializer
child = self.root.getChildByValueElement(self.ed)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'getChildByValueElement'
```
A minimal example and testcase is added.
The extra check for nextChild seems to fix it, however i did not read
the whole codebase, so maybe this creates other issues.
---------
Co-authored-by: Tim Blume <tbl@sevenstax-intern.de>
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.
Oliver Stöneberg
chrchr-github
Daniel Marjamäki
Paul Fultz II
Tim Blume
Valentin Batz
Anton Lindqvist