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.
I also changed the comment header to run tests on misra-test-avr8.c
because I thought that was the intention to use it like misra-test.c; if
not, I can revert.
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.
Oliver Stöneberg
Daniel Marjamäki
Paul Fultz II
Tim Blume
chrchr-github
Valentin Batz
Anton Lindqvist
andymacg