[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [XEN PATCH] xen/bitmap: remove comment-based deviations
On 30.08.2024 10:13, Federico Serafini wrote: > 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. Please do,taking into consideration also language extensions that we use, e.g. the statements-as-expressions one (where figure braces exist inside an expression). Jan
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |