Re: [XEN PATCH][for-4.19 v3] xen: address violations of Rule 11.9

[Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>]

On 19/10/2023 09:03, Jan Beulich wrote:
> On 19.10.2023 02:54, Stefano Stabellini wrote:
> > On Thu, 19 Oct 2023, andrew.cooper3@xxxxxxxxxx wrote:
> > > On 18/10/2023 2:42 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.
> > > This is still deeply misleading.
> > >
> > > There is an integer, which happens to be 0 but could be anything, 
> > > used
> > > for a compile time typecheck[1].  In some cases this may be 
> > > interpreted
> > > as a pointer constant, and is permitted for this purpose.
> > >
> > > ~Andrew
> > >
> > > [1] I know I wrote scalar typecheck in the comment, but I suspect 
> > > that
> > > what I actually meant was non-compound-type typecheck.
> > To help Nicola find the right wording do you have a concrete 
> > suggestion
> > for the text to use?
> >
> > Reading your reply, I am guessing it would be:
> >
> > * - R11.9
> >   - __ACCESS_ONCE uses an integer, which happens to be zero, as a
> >     non-compound-type typecheck. The typecheck uses a cast. The usage 
> > of
> >     zero or other integers for this purpose is allowed.
> "non-compound" isn't correct either: __int128_t, for example, isn't a
> compound type but may not be used with ACCESS_ONCE(). Furthermore
> certain compound types are, as indicated earlier, in principle okay
> to use with ACCESS_ONCE(). Both are shortcomings of the present
> implementation, which imo shouldn't propagate into this document. I'd
> say just "as a compile time check".
>
> Jan
Ok, I'll amend it

--
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)