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. I think we should take this patch for now and harmonize it once SAF is improved.
