The R11.1 safe cast only matched void noreturn (*)(void *). Accept a
conversion where noreturn is omitted and the signature is otherwise
compatible. canonical() covers typeof destinations, and
compatible_deep_unqualified keeps the parameter and return types aligned.
Discarding noreturn does not change the calling convention. Code after
the call is unreachable when every possible callee is noreturn. Leaving
that code in place is a tolerated Rule 2.1 violation. The full rationale
is in docs/misra/deviations.rst.
Signed-off-by: Dmytro Prokopchuk <dmytro_prokopchuk1@epam.com>
Acked-by: Nicola Vetrini <nicola.vetrini@bugseng.com> # automation/eclair_analysis/.*
Acked-by: Jan Beulich <jbeulich@suse.com>
MISRA C Rule 5.5 states: "Identifiers shall be distinct from macro
names".
Update ECLAIR configuration to deviate identifier and macro name
clashes by specifying the macros that should be ignored.
This includes hypfs_alloc_dyndata(), where the real function takes
an allocation size and the same-named macro is a typed convenience
wrapper that expands calls using sizeof(type).
Update deviations.rst and rules.rst accordingly.
Signed-off-by: Dmytro Prokopchuk <dmytro_prokopchuk1@epam.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
What is true for unsigned long is also true for plain/signed long, thus
also taking care of two instances of __x86_return_thunk() being cast to
long.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
xen/drivers/passthrough/arm/ipmmu-vmsa.c contains a git:// URL in a block
comment. This is also not an example of commented out code, so shouldn't be
considered a R3.1 violation.
Extend the regex to include git://, and swap hyperlink for URL in the
associated documentation to be more precise.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Rule 11.1 states as following: "Conversions shall not be performed
between a pointer to a function and any other type."
This deviation from Rule 11.1 relies on both ABI definitions and compiler
implementations supported by Xen. The System V x86_64 ABI and the AArch64
ELF ABI define consistent and compatible representations (i.e., having
the same size and memory layout) for (void *), unsigned long, and function
pointers, enabling safe conversions between these types without data loss
or corruption. Additionally, GCC and Clang, faithfully implement the ABI
specifications, ensuring that the generated machine code conforms to these
guarantees. Developers must note that this behavior is not universal and
depends on platform-specific ABIs and compiler implementations.
Configure Eclair to avoid reporting violations for conversions from
unsigned long or (void *) to a function pointer.
Add a compile-time assertion into the file 'xen/common/version.c' to
confirm this conversion compatibility across X86 and ARM platforms
(assuming this file is common for them).
References:
- System V x86_64 ABI: https://gitlab.com/x86-psABIs/x86-64-ABI/-/jobs/artifacts/master/raw/x86-64-ABI/abi.pdf?job=build
- AArch64 ELF ABI: https://github.com/ARM-software/abi-aa/releases
- GCC: https://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html
- Clang: https://clang.llvm.org/docs/CrossCompilation.html
Signed-off-by: Dmytro Prokopchuk <dmytro_prokopchuk1@epam.com>
Reviewed-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
[stefano: remove special powerpc check]
Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
Fix the following issues:
1. xen/docs/misra/deviations.rst:90: WARNING: Inline interpreted text or
phrase reference start-string without end-string. [docutils]
2. xen/docs/misra/deviations.rst:54: ERROR: Error parsing content block
for the "list-table" directive: uniform two-level bullet list expected,
but row 6 does not contain the same number of items as row 1 (2 vs 3).
* - R2.1
- Calls to the `__builtin_unreachable()` function inside the expansion of
the `ASSERT_UNREACHABLE()` macro may cause a function to be marked as
non-returning. This behavior occurs only in configurations where
assertions are enabled. To address this, the `noreturn` property for
`__builtin_unreachable()` is overridden in these contexts, resulting in
the absence of reports that do not have an impact on safety, despite
being true positives.
Xen expects developers to ensure code remains safe and reliable in builds,
even when debug-only assertions like `ASSERT_UNREACHABLE() are removed.
3. xen/docs/misra/rules.rst:127: WARNING: Inline interpreted text or phrase
reference start-string without end-string. [docutils]
Signed-off-by: Dmytro Prokopchuk <dmytro_prokopchuk1@epam.com>
Reviewed-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
MISRA C Rule 5.5 states: "Identifiers shall be distinct from macro names".
Update ECLAIR configuration to deviate clashes: specify the macros that
should be ignored. Update deviations.rst and rules.rst accordingly.
Signed-off-by: Dmytro Prokopchuk <dmytro_prokopchuk1@epam.com>
Reviewed-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
The conversion from a function pointer with the 'noreturn' attribute
('void noreturn (*)(...)') to a function pointer type ('void (*)(...)'
causes type incompatibility according to MISRA C Rule 11.1, which
forbids conversions between incompatible function pointer types.
The violation occurs at the call site:
smp_call_function(halt_this_cpu, NULL, 0);
where 'halt_this_cpu' with type 'void noreturn (*)(void *)' is passed to
'smp_call_function' expecting function pointer of type 'void (*)(void *)'.
The 'noreturn' attribute does not change the function calling convention
or parameter handling at runtime, making the conversion safe.
For now, configure Eclair to just treat implicit conversions that lose
the "noreturn" attribute on a function 'void (*)(void*)' as safe.
Signed-off-by: Dmytro Prokopchuk <dmytro_prokopchuk1@epam.com>
Acked-by: Jan Beulich <jbeulich@suse.com> # docs
Reviewed-by: Nicola Vetrini <nicola.vetrini@bugseng.com> # ECLAIR
MISRA C Rule 2.1 states: "A project shall not contain unreachable code".
Functions that are non-returning and are not explicitly annotated with
the `noreturn' attribute are considered a violation of this rule.
In certain cases, some functions might be non-returning in specific build
configurations (when assertions are enabled, i.e., when `NDEBUG' is not
defined). This is due to calls to `__builtin_unreachable()' in the
expansion of the macro `ASSERT_UNREACHABLE()'.
Conversely, in builds where `NDEBUG' is defined (assertions are disabled),
the macro `ASSERT_UNREACHABLE()' expands to an empty construct
(`do { } while (0)'), which does not affect the execution flow. This allows
such functions to return normally in such builds, avoiding unreachable code.
To account for that in specific builds, the `noreturn` property of
`__builtin_unreachable()` is overridden in the ECLAIR configuration to
deviate these violations.
Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Signed-off-by: Dmytro Prokopchuk <dmytro_prokopchuk1@epam.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Rule 21.16 is about the types of arguments allowed for memcmp. Add
string literals to the allow-list under specific conditions.
Suggested-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
MISRA C Rule 20.7 states:
"Expressions resulting from the expansion of macro parameters shall
be enclosed in parentheses".
Document the behaviour of ECLAIR with respect to the CPP extension
that allows variable macro arguments to be named.
Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Currently the identifiers characters limit is arbitrarily set to 40. It
causes a few violations as we have some identifiers longer than 40.
Increase the limit to another rather arbitrary limit of 63. Thanks to
this change, we remove a few violations, getting us one step closer to
marking Rules 5.2 and 5.4 as clean.
The ECLAIR configuration is already using 63, so this change matches
the rules.rst documentation with the ECLAIR behavior.
Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
Reviewed-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
The Xen community is already informally following both rules. Let's make
it explicit. Both rules have zero violations, only cautions. While we
want to go down to zero cautions in time, adding both rules to rules.rst
enables us to immediately make both rules gating in the ECLAIR job part
of gitlab-ci.
Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
Acked-by: Bertrand Marquis <bertrand.marquis@arm.com>
Add MISRA C rules 13.2 and 18.2 to rules.rst. Both rules have zero
violations reported by Eclair but they have some cautions. We accept
both rules and for now we'll enable scanning for them in Eclair but only
violations will cause the Gitlab CI job to fail (cautions will not.)
Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
Acked-by: Bertrand Marquis <bertrand.marquis@arm.com>
In practice, we are already following R18.6 and we have zero violations
reported by ECLAIR (there are some cautions being reported.)
Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
Acked-by: Bertrand Marquis <bertrand.marquis@arm.com>
As discussed during the last MISRA C meeting, add Rule 12.2 to the list
of MISRA C rules we accept, together with an explanation that we use gcc
-fsanitize=undefined to check for violations.
Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
This patch adds a bunch of rules to rules.rst that are uncontroversial
and have zero violations in Xen. As such, they have been approved for
adoption.
All the ones that regard the standard library have the link to the
existing footnote in the notes.
Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Add a section for terms and definitions used by MISRA but expressed
in terms of the C specification.
Add a definition of "switch clause" to the newly-introduced section.
Link the first use of the term "switch clause" in the document to its
definition.
Suggested-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Federico Serafini <federico.serafini@bugseng.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
These deviations deal with the following cases:
- macro arguments used directly as initializer list arguments;
- uses of the __config_enabled macro, that can't be brought
into compliance without breaking its functionality;
- exclude files that are out of scope (efi headers and cpu_idle);
- uses of alternative_{call,vcall}[0-9] macros.
The existing configuration for R20.7 is reordered so that it matches the
cases listed in its documentation comment.
Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
As agreed during MISRA C meetings, add Rule 13.6 to rules.rst, with a
note about extending the rule to alignof and typeof. Also take the
opportunity to remove an older and out of order entry for the same rule.
Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Commit 4cac80e226 broke the CI cppcheck jobs by adding an entry for
a rule 20.12 with "Severity" and "Summary" fields placed in reverse order.
This leads to an error as reported by convert_misra_doc.py:
No summary for rule 20.12
Fixes: 4cac80e226 ("docs/misra/rules.rst: add rule 16.6 and 20.12")
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
Add the rules accepted in the last three MISRA C working group meetings.
Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Add 21.1 and 21.2, with a longer comment to explain how strategy with
leading underscores and why we think we are safe today.
Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Add MISRA C Rules 11.1, 11.2, 11.3, 11.6 as discussed.
Explicitly add in the notes that conversions to integer types are
permitted if the destination type has enough bits to hold the entire
value. GCC gives enough guarantees in terms of preserving the bit
content in such situations.
Also allow for bool conversions (e.g. to check if a function point is
valid).
Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Using enumerators declared in a named enum, such as the one modified,
as operands to arithmetic operators is not allowed by MISRA C:2012 Rule 10.1.
The enumerators of an anonymous enum can be used instead.
Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
The aforementioned directive requires the project to supply documentation
on the measures taken towards the minimization of run-time failures.
The actual content of the documentation still needs feedback from the
community.
The 'rules.rst' file is updated accordingly to mention the newly
added documentation.
Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
This file contains the deviation that are not marked by
a deviation comment, as specified in
docs/misra/documenting-violations.rst.
Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Release-acked-by: Henry Wang <Henry.Wang@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
During the discussions that led to the acceptance of Rule 2.1, we
decided on a few exceptions that were not properly recorded in
rules.rst. Add them now.
Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Bertrand Marquis <bertrand.marquis@arm.com>
Release-acked-by: Henry Wang <Henry.Wang@arm.com>
Add 14.3, with project-wide deviations.
Also take the opportunity to clarify that parameters of function pointer
types are expected to have names (Rule 8.2).
Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Bertrand Marquis <bertrand.marquis@arm.com>
Release-acked-by: Henry Wang <Henry.Wang@arm.com>
As per the last MISRA C group discussion, let's accept 11.7 (for which
we have no violations) and 11.8.
Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
10.1 with several caveats, described in the notes.
10.3 and 10.4 as "aspirational" guidelines, as clarified in the notes.
Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
During the discussions that led to the acceptance of the Rules, we
decided on a few exceptions that were not properly recorded in
rules.rst. Other times, the exceptions were decided later when it came
to enabling a rule in ECLAIR.
Either way, update rules.rst with appropriate notes.
Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Rule 1.1 is uncontroversial and we are already following it.
Rule 5.6 has been deemed a good rule to have by the MISRA C group.
However, we do have a significant amount of violations that will take
time to resolve and might require partial deviations in the form of
in-code comments or MISRA C scanners special configurations (ECLAIR).
For new code, we want this rule to generally apply hence the addition to
docs/misra/rules.rst.
Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Rule 9.4 is non-controversial and we have no violations.
Rule 7.4 is considered a good idea with the caveat that assigning a
string literal to const void is allowed. I added a note to specify it.
Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
It creates confusion since the new format of documenting violations can
be found in: docs/misra/documenting-violations.rst.
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
For Dir 1.1, a document describing all implementation-defined behaviour
(i.e. gcc-specific behavior) will be added to docs/misra, also including
implementation-specific (gcc-specific) appropriate types for bit-field
relevant to Rule 6.1.
Rule 21.21 is lacking an example on gitlab but the rule is
straightforward: we don't use stdlib at all in Xen.
Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
Dmytro Prokopchuk