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.
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.
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.
Daniel Marjamäki
Oliver Stöneberg
Tim Blume
chrchr-github
Valentin Batz
Anton Lindqvist
Paul Fultz II
andymacg