[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [XEN PATCH] xen/bitmap: remove comment-based deviations



On 28/08/24 16:50, Jan Beulich wrote:
On 28.08.2024 15:12, Federico Serafini wrote:
--- a/automation/eclair_analysis/ECLAIR/deviations.ecl
+++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
@@ -565,6 +565,10 @@ of this macro do not lead to developer confusion, and can thus 
be deviated."
  -config=MC3R1.R20.7,reports+={safe, 
"any_area(any_loc(any_exp(macro(^count_args_$))))"}
  -doc_end
+-doc_begin="The expansion of an argument surrounded by tokens '{', '}' and ';' is safe."
+-config=MC3R1.R20.7,expansion_context+={safe, "left_right(^[\\{;]$,^[;\\}]$)"}
+-doc_end

Not the least because this is quite a bit wider than ...

--- a/xen/include/xen/bitmap.h
+++ b/xen/include/xen/bitmap.h
@@ -103,13 +103,10 @@ extern int bitmap_allocate_region(unsigned long *bitmap, 
int pos, int order);
  #define bitmap_switch(nbits, zero, small, large)                        \
        unsigned int n__ = (nbits);                                       \
        if (__builtin_constant_p(nbits) && !n__) {                        \
-               /* SAF-7-safe Rule 20.7 non-parenthesized macro argument */ \
                zero;                                                     \
        } else if (__builtin_constant_p(nbits) && n__ <= BITS_PER_LONG) { \
-               /* SAF-7-safe Rule 20.7 non-parenthesized macro argument */ \
                small;                                                    \
        } else {                                                          \
-               /* SAF-7-safe Rule 20.7 non-parenthesized macro argument */ \
                large;                                                    \
        }

... what's needed here, I wonder if we're not opening up avenues to
problems by generally permitting that pattern. Plus in the description
I'm missing a statement to the effect of why this is (always) safe.

The rational of the rule is that if a macro argument expands to an
expression, there may be problems related to operator precedence, e.g.:

#define A(x, y) x * y

A(1+1, 2+2) will expand to: 1+1 * 2+2

Yes, the deviation is more general and wider than what is needed for
the specific case but it is safe: if the expanded argument is between
one of the aforementioned tokens, then there are no operators involved
and no precedence issues.

I can add some details in a v2.

--
Federico Serafini, M.Sc.

Software Engineer, BUGSENG (http://bugseng.com)



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.