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

Re: [XEN PATCH][for-4.19 v5] xen: Add deviations for MISRA C:2012 Rule 7.1



Hi Julien, Stefano

On 2023-10-31 22:41, Stefano Stabellini wrote:
On Tue, 30 Oct 2023, Julien Grall wrote:
Hi Stefano,

On 30/10/2023 22:49, Stefano Stabellini wrote:
> On Mon, 30 Oct 2023, Julien Grall wrote:
> > Hi Nicola,
> >
> > On 27/10/2023 16:11, Nicola Vetrini wrote:
> > > diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst
> > > index 8511a189253b..8aaaa1473fb4 100644
> > > --- a/docs/misra/deviations.rst
> > > +++ b/docs/misra/deviations.rst
> > > @@ -90,6 +90,13 @@ Deviations related to MISRA C:2012 Rules:
> > >             - __emulate_2op and __emulate_2op_nobyte
> > >             - read_debugreg and write_debugreg
> > >    +   * - R7.1
> > > +     - It is safe to use certain octal constants the way they are
> > > defined
> > > +       in specifications, manuals, and algorithm descriptions. Such
> > > places
> > > +       are marked safe with a /\* octal-ok \*/ in-code comment, or with
> > > a
> > > SAF
> > > +       comment (see safe.json).
> >
> > Reading this, it is unclear to me why we have two ways to deviate the rule
> > r7.1. And more importantely, how would the developper decide which one to
> > use?
>
> I agree with you on this and we were discussing this topic just this
> morning in the FUSA community call. I think we need a way to do this
> with the SAF framework:
>
> if (some code with violation) /* SAF-xx-safe */
>
> This doesn't work today unfortunately. It can only be done this way:
>
> /* SAF-xx-safe */
> if (some code with violation)
>
> Which is not always desirable. octal-ok is just an ad-hoc solution for
> one specific violation but we need a generic way to do this. Luca is
> investigating possible ways to support the previous format in SAF.

Why can't we use octal-ok everywhere for now?

I think this is a good option for now, yes


My point here is to make simple for the developper to know what to use.

>
> I think we should take this patch for now and harmonize it once SAF is
> improved.

The description of the deviation needs some improvement.

+1


To give an example,
with the current wording, one could they can use octal-ok everywhere. But
above, you are implying that SAF-xx-safe should be
preferred.

I would still strongly prefer if we use octal-ok everywhere because this is
simple to remember. But if the other are happy to have both SAF-XX and
octal-ok, then the description needs to be completely unambiguous and the patch should contain some explanation why we have two different ways to
deviate.

I think we could say "octal-ok" only and not mention SAF. As you can see
from the other messages we still have work to do on SAF to be able to
use it the way we would like to use it.

Thanks for the feedback; I'll revise the patch to use and mention only octal-ok.

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



 


Rackspace

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