Re: [XEN PATCH][for-4.19 v2 1/1] xen: introduce a deviation for Rule 11.9

[Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>]

On 11/10/2023 18:56, andrew.cooper3@xxxxxxxxxx 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)