Re: [XEN PATCH 08/11] x86/altcall: address violations of MISRA C Rule 20.7

[Jan Beulich <jbeulich@xxxxxxxx>]

On 22.03.2024 17:01, Nicola Vetrini wrote:
> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
> of macro parameters shall be enclosed in parentheses". Therefore, some
> macro definitions should gain additional parentheses to ensure that all
> current and future users will be safe with respect to expansions that
> can possibly alter the semantics of the passed-in macro parameter.
> 
> No functional change.
> 
> Signed-off-by: Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>

Hmm. These macros are, at least in part, hard to read already. The added
parentheses, while necessary when following the rule to the letter, are
making things worse, even if just slightly. I therefore have a proposal /
question:

> --- a/xen/arch/x86/include/asm/alternative.h
> +++ b/xen/arch/x86/include/asm/alternative.h
> @@ -243,28 +243,28 @@ extern void alternative_branches(void);
>  
>  #define alternative_vcall0(func) ({             \
>      ALT_CALL_NO_ARG1;                           \
> -    (void)sizeof(func());                       \
> +    (void)sizeof((func)());                     \

Like this, all that's touched here are (syntactical, but not real) function
invocations. Function calls, like all postfix operators, are highest
precedence. Hence by omitting parentheses in that case no breakage can
happen as a result: If the passed expression is another postfix one, that'll
be evaluated first anyway. If any other expression is passed (aside primary
ones, of course), that'll be evaluated afterwards only due to being lower
precedence, irrespective of the presence/absence of parentheses.

Therefore, where harmful to readability, can we perhaps leave postfix
expressions alone?

Jan