Add some more tests for rule 10.1. They are given as examples in the
MISRA document. The 10.1 test that causes a false positive for 10.6 can be
found under the 10.6 tests.
Track ticket for false positive:
https://trac.cppcheck.net/ticket/9488
Trac ticket for the false negative:
https://trac.cppcheck.net/ticket/9489
* cert.py: Add ENV33-C-EX1 exception
ENV33-C-EX1: It is permissible to call system() with a null pointer
argument to determine the presence of a command processor for the
system. [1]
[1]: https://wiki.sei.cmu.edu/confluence/pages/viewpage.action?pageId=87152177
* Handle different null-pointer constants
* cppcheck.cpp: Check for JSON error when parsing addon .json files
This fixes that errors in JSON files given via `--addon=*.json` are
silently ignored and maybe only a part of the JSON file is used.
Now the error message which picojson can return is checked and a
corresponding error message is returned again by getAddonInfo().
* naming.json: Fix missing comma
* CLI: Fix naming violations detected by addon naming.py via naming.json
* Addon naming: Add argument for validating names of constants
* LIB: Rename functions/variables so they are valid, loosen naming rules
* GUI: Fix naming violations
The unused argument causes the new check for rule 2.7 to output an error
here.
I verified that the regression test still works without the unused
argument (misra.py would still crash).
Travis should be happy again.
* Add check for MISRA-C 2012 Rule 2.7 and test cases.
* Cast unused function parameters of some test patterns to "void".
* Fix function parameter void cast in "misra_17_6". Add comment to "misra_11_7_extra" to make all function parameter void casts look alike.
Use Python 3 instead of Python 2 if addons are executed directly.
Running cert.py and misra.py against test/cfg/std.c.dump shows that
Python 3 needs only half the time compared to Python 2. I have tested
it repeatedly and the results are always the same. This is no surprise
at all. The memory footprint is very likely also significantly better
but i have not tested it.
* addons: Add '--recursive' arg. Clean up and clarify errors messages.
This commit introduce '--recursive' option for cppcheck addons.
Iff this option is set addon will recursively traverse directories in
given input files to find files with '.dump' suffix that would be
checked. Otherwise it will treat input directory as error (current
behaviour).
Add additional error handling with more clear error messages, clean up
the code.
* Add regex specifier
* Roll back --recursive option
* Update addons section in manual
Rule 21.1 now doesn't report errors on usage of library functions
started from underscore (e.g. `_exit') and valid errno assignment.
See added tests for examples.
Fix R16.3 state machine which doesn't report errors in last case/default
statemenet. See added tests for examples.
Issue on trac: https://trac.cppcheck.net/ticket/8548
* misra.py: Fix large memory usage with suppressions
Don't save whole lxml locations when collecting rules suppressions
statistics. This fixes the problem with large memory usage when
some rules are suppressed.
See issue description:
https://sourceforge.net/p/cppcheck/discussion/development/thread/51fc053626/
* don't override 'file' builtin
These changes will improve misra.py execution time in the
case where we use globally suppressed checks. For example, when using
single MISRA rule and suppress others, we could get about twice the
execution speed, since most of `MisraChecker' class methods will not
be started at all.
Some measurements and discussion are available at:
https://github.com/danmar/cppcheck/pull/2301
Version 1.88 changed the parsing of the MISRA rules file adding a
severity setting. This caused a regression in rule parsing.
In particular the following format used to parse cleanly and produce
rule output that would show the severity as part of the rule text.
Rule 1.2
Advisory
Rule text goes here.
Rule 1.3
Required
More rule text goes here.
As of 1.88 a file structured like above would parse as having no rules.
The problem is the use of blank lines as a rule delimiter. The
modified rule parser wants to see a rules formatted like below:
Rule 3.1 Required
R3.1 text.
Rule 4.1 Required
R4.1 text.
or:
Rule 1.1
Add this rule and parse to next, skipping empty lines.
Rule 1.2
Rule text.
Any rule text that did not fall into one of the above formats would
result in incomplete rule text parsing.
Change the parsing of the rule text file so that blank lines are ignored
instead of treating them as a delimiter between rules. Instead use the
start of the next rule as a delimiter for the end of the previous rule.
This allows both of the newer formats but also supports the behavior of
pre-1.88 versions.
Change units tests that were specifically forbidding the use of blank
lines to ones that allow blank lines.
* make ellipsis ... a single token
Using cppcheck -E to preprocess code with ellipsis produces output that
can't be compiled because ... is split into 3 tokens.
* try to fix addon