Re: [XEN PATCH 1/2] xen: apply deviation for Rule 8.4 (asm-only definitions)

[Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>]

On 04/09/2023 09:02, Jan Beulich wrote:
> On 01.09.2023 18:34, Nicola Vetrini wrote:
> > As stated in 'docs/misra/rules.rst' the functions that are used only 
> > by
> > asm modules do not need to conform to MISRA C:2012 Rule 8.4.
> > The deviations are carried out with a SAF comment.
> >
> > Signed-off-by: Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>
> > ---
> > Where the identifier for a function definition is on the next line 
> > w.r.t. the
> > return type, they have been put on the same line (e.g. efi_start) to 
> > avoid
> > stylistically questionable constructs, such as
> >
> > int
> > /* SAF-1-safe */
> > func(void) {
> >         ...
> > }
> And
>
> /* SAF-1-safe */
> int
> func(void) {
>
> is not an option?
Not at the moment, as it would deviate the line with the return type and 
not the one below,
and this is not configurable in the scripts under 
xen/scripts/xen-analysis:
/* SAF-1-safe */ -> /* -E> safe ... 1 */
int                 int
func(void)          func(void)

As I said, this can perhaps be solved by allowing markers to specify 
either a row count, such as
/* SAF-1-safe 2 */ -> /* -E> safe ... 2 */
int                   int
func(void)            func(void)

or count the line span of the whole function declarator in the python 
script and translating
/* SAF-1-safe */ -> /* -E> safe ... 2 */.

> Further in the cover letter you say "Deviating variables needs more 
> care, and
> is therefore postponed to another patch", yet then here you annotate a 
> couple
> of variables as well. Could you clarify what the criteria are for 
> "needs more
> care"?
I see. I did not intend for those changes to end up in this patch, 
although those two are
clearly only used by asm code and therefore are excepted.
Most of the variables I left out are also used by C code, therefore they 
may be eligible for
a declaration, but where to put this declaration requires a careful 
examination in my opinion.
They are not too many, tough.

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