On 11/10/2023 18:56, andrew.coop...@citrix.com wrote:
On 11/10/2023 8:46 pm, Nicola Vetrini wrote:
diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst
index ee7aed0609d2..1b00e4e3e9b7 100644
--- a/docs/misra/deviations.rst
+++ b/docs/misra/deviations.rst
@@ -199,6 +199,11 @@ Deviations related to MISRA C:2012 Rules:
See automation/eclair_analysis/deviations.ecl for the full
explanation.
- Tagged as `safe` for ECLAIR.
+ * - R11.9
+ - __ACCESS_ONCE uses a 0 as a null pointer constant to check if
a type is
+ scalar, therefore its usage for this purpose is allowed.
+ - Tagged as `deliberate` for ECLAIR.
Really?
#define __ACCESS_ONCE(x)
(void)(typeof(x))0; /* Scalar typecheck. */
That's not a pointer.
If someone were to pass in an x who's type was pointer-to-object, then
yes it is technically a NULL pointer constant for long enough for the
build to error out.
What justification is Eclair using to suggest that it is a pointer?
If you really really want to shut things up, it doesn't need to be 0 -
it could be 1 or any other integer, but this honestly feels like a bug
in Eclair to me.
~Andrew
The non-compliant uses found by the checker were due to function
pointers
e.g.
void (*fp)(int i);
violation for rule MC3R1.R11.9: (required) The macro `NULL' shall be the
only permitted form of integer null pointer constant. (untagged)
p.c:12.3-12.7: (MACRO) Loc #1 [culprit: non-compliant use of null
pointer constant]
A(fp) = NULL;
<~~~>
p.c:6.8-6.19: for #1 [culprit: expanded from macro `_A']
(void)(typeof(X))0; \
<~~~~~~~~~~>
p.c:9.16-9.20: for #1 [culprit: expanded from macro `A']
#define A(X) (*_A(X))
<~~~>
These uses do not cause a build fail, and we deemed this usage of 0 to
be correct
(a neutral value that would allow __ACCESS_ONCE to support any type of
argument).
While perhaps some other value does have the same property (e.g., 1), we
felt that it was
okay to let 0 remain there.
--
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)
