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

[Nicola Vetrini <nicola.vetrini@bugseng.com>]

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@bugseng.com>
>> ---
>> 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)