On 2024-03-25 10:38, Jan Beulich wrote:
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.vetr...@bugseng.com>
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
While I can understand the benefits of this, and the reasoning on
postfix expressions, what about, for instance (modulo the actual
invocation, this is just an example)
alternative_vcall0(2 + f) or similar scenarios?
--
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)
