From de21b500029425466e746da3b4475cb3717cb0df Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Benjamin=20Cab=C3=A9?= Date: Fri, 19 Jan 2024 18:30:03 +0100 Subject: [PATCH] doc: guidelines: drop mentions of Parasoft Codescan MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Drop the section of the coding guidelines that's referring to Parasoft Codescan as it's not used by the project anymore. Signed-off-by: Benjamin Cabé --- doc/contribute/coding_guidelines/index.rst | 99 ---------------------- 1 file changed, 99 deletions(-) diff --git a/doc/contribute/coding_guidelines/index.rst b/doc/contribute/coding_guidelines/index.rst index f3bcecddfd..69a159d957 100644 --- a/doc/contribute/coding_guidelines/index.rst +++ b/doc/contribute/coding_guidelines/index.rst @@ -1481,102 +1481,3 @@ toolchains that come with their own C standard libraries. .. _main Zephyr repository: https://github.com/zephyrproject-rtos/zephyr .. _strnlen(): https://pubs.opengroup.org/onlinepubs/9699919799/functions/strlen.html .. _strtok_r(): https://pubs.opengroup.org/onlinepubs/9699919799/functions/strtok.html - -Parasoft Codescan Tool -********************** - -Parasoft Codescan is an official static code analysis tool used by the Zephyr -project. It is used to automate compliance with a range of coding and security -standards. -The tool is currently set to the MISRA-C:2012 Coding Standard because the Zephyr -:ref:`coding_guidelines` are based on that standard. -It is used together with the Coverity Scan tool to achieve the best code health -and precision in bug findings. - -Violations fixing process -========================= - -Step 1 - Any Zephyr Project member, company or a developer can request access - to the Parasoft reporting centre if they wish to get involved in fixing - violations by submitting issues. - -Step 2 - A developer starts to review violations. - -Step 3 - A developer submits a Github PR with the fix. Commit messages should follow - the same guidelines as other PRs in the Zephyr project. Please add a comment - that your fix was found by a static coding scanning tool. - Developers should follow and refer to the Zephyr :ref:`coding_guidelines` - as basic rules for coding. These rules are based on the MISRA-C standard. - - Below you can find an example of a recommended commit message:: - - lib: os: add braces to 'if' statements - - An 'if' (expression) construct shall be followed by a compound statement. - Add braces to improve readability and maintainability. - - Found as a coding guideline violation (Rule 15.6) by static - coding scanning tool. - - Signed-off-by: Johnny Developer - -Step 4 - If a violation is a false positive, the developer should mark it for the Codescan - tool just like they would do for the Coverity tool. - The developer should also add a comment to the code explaining that - the violation raised by the static code analysis tool should be considered a - false positive. - -Step 5 - If the developer has found a real violation that the community decided to ignore, - the developer must submit a PR with a suppression tag - and a comment explaining why the violation has been deviated. - The template structure of the comment and tag in the code should be:: - - /* Explain why that part of the code doesn't follow the standard, - * explain why it is a deliberate deviation from the standard. - * Don't refer to the Parasoft tool here, just mention that static code - * analysis tool raised a violation in the line below. - */ - code_line_with_a_violation /* parasoft-suppress Rule ID */ - - Below you can find an example of a recommended commit message:: - - testsuite: suppress usage of setjmp in a testcode (rule 21.4) - - According to the Rule 21.4 the standard header file shall not - be used. We will suppress this violation because it is in - test code. Tag suppresses reporting of the violation for the - line where the violation is located. - This is a deliberate deviation. - - Found as a coding guideline violation (Rule 21.4) by static coding - scanning tool. - - Signed-off-by: Johnny Developer - - The example below demonstrates how deviations can be suppressed in the code:: - - /* Static code analysis tool can raise a violation that the standard - * header shall not be used. - * Since this violation is in test code, we will suppress it. - * Deliberate deviation. - */ - #include /* parasoft-suppress MISRAC2012-RULE_21_4-a MISRAC2012-RULE_21_4-b */ - - This variant above suppresses item ``MISRAC2012-RULE_21_4-a`` and ``MISRAC2012-RULE_21_4-b`` - on the line with "setjump" header include. You can add as many rules to suppress you want - - just make sure to keep the Parasoft tag on one line and separate rules with a space. - To read more about suppressing findings in the Parasoft tool, refer to the - official Parasoft `documentation`_ - - .. _documentation: https://docs.parasoft.com/display/CPPTEST1031/Suppressing+Findings - -Step 6 - After a PR is submitted, the developer should add the ``Coding guidelines`` - and ``MISRA-C`` Github labels so their PR can be easily tracked by maintainers. - If you have any concerns about what your PR should look like, you can search - on Github using those tags and refer to similar PRs that have already been merged.