[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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.

Andrew, please confirm? Nicola, please also confirm that this version of
the text would be suitable for an assessor.

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.