[XEN PATCH 0/6] address several violations of MISRA Rule 20.7

[XEN PATCH 0/6] address several violations of MISRA Rule 20.7

[Nicola Vetrini]

Hi all,

this series addresses several violations of Rule 20.7, as well as a
small fix to the ECLAIR integration scripts that do not influence
the current behaviour, but were mistakenly part of the upstream
configuration.

Note that by applying this series the rule has a few leftover violations.
Most of those are in x86 code in xen/arch/x86/include/asm/msi.h .
I did send a patch [1] to deal with those, limited only to addressing the MISRA
violations, but in the end it was dropped in favour of a more general cleanup of
the file upon agreement, so this is why those changes are not included here.

[1] https://lore.kernel.org/xen-devel/2f2c865f20d0296e623f1d65bed25c083f5dd497.1711700095.git.nicola.vetrini@bugseng.com/

Nicola Vetrini (6):
  automation/eclair: address violations of MISRA C Rule 20.7
  xen/self-tests: address violations of MISRA rule 20.7
  xen/guest_access: address violations of MISRA rule 20.7
  x86emul: address violations of MISRA C Rule 20.7
  x86/irq: address violations of MISRA C Rule 20.7
  automation/eclair_analysis: clean ECLAIR configuration scripts

 automation/eclair_analysis/ECLAIR/analyze.sh     | 3 +--
 automation/eclair_analysis/ECLAIR/deviations.ecl | 8 ++++++++
 xen/arch/x86/x86_emulate/x86_emulate.c           | 4 ++--
 xen/include/xen/guest_access.h                   | 4 ++--
 xen/include/xen/irq.h                            | 2 +-
 xen/include/xen/self-tests.h                     | 8 ++++----
 6 files changed, 18 insertions(+), 11 deletions(-)

-- 
2.34.1

[XEN PATCH 1/6] automation/eclair: address violations of MISRA C Rule 20.7

[Nicola Vetrini]

MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses".

The helper macro bitmap_switch has parameters that cannot be parenthesized
in order to comply with the rule, as that would break its functionality.
Moreover, the risk of misuse due developer confusion is deemed not
substantial enough to warrant a more involved refactor, thus the macro
is deviated for this rule.

No functional change.

Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
---
 automation/eclair_analysis/ECLAIR/deviations.ecl | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl
index 447c1e6661d1..c2698e7074aa 100644
--- a/automation/eclair_analysis/ECLAIR/deviations.ecl
+++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
@@ -463,6 +463,14 @@ 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 arguments of macro bitmap_switch macro can't be parenthesized as
+the rule would require, without breaking the functionality of the macro. This is
+a specialized local helper macro only used within the bitmap.h header, so it is
+less likely to lead to developer confusion and it is deemed better to deviate it."
+-file_tag+={xen_bitmap_h, "^xen/include/xen/bitmap\\.h$"}
+-config=MC3R1.R20.7,reports+={safe, "any_area(any_loc(any_exp(macro(loc(file(xen_bitmap_h))&&^bitmap_switch$))))"}
+-doc_end
+
 -doc_begin="Uses of variadic macros that have one of their arguments defined as
 a macro and used within the body for both ordinary parameter expansion and as an
 operand to the # or ## operators have a behavior that is well-understood and
-- 
2.34.1

[XEN PATCH 2/6] xen/self-tests: address violations of MISRA rule 20.7

[Nicola Vetrini]

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@bugseng.com>
---
In this case the use of parentheses can detect misuses of the COMPILE_CHECK
macro for the fn argument that happen to pass the compile-time check
(see e.g. https://godbolt.org/z/n4zTdz595).

An alternative would be to deviate these macros, but since they are used
to check the correctness of other code it seemed the better alternative
to futher ensure that all usages of the macros are safe.
---
 xen/include/xen/self-tests.h | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/xen/include/xen/self-tests.h b/xen/include/xen/self-tests.h
index 42a4cc4d17fe..58484fe5a8ae 100644
--- a/xen/include/xen/self-tests.h
+++ b/xen/include/xen/self-tests.h
@@ -19,11 +19,11 @@
 #if !defined(CONFIG_CC_IS_CLANG) || CONFIG_CLANG_VERSION >= 80000
 #define COMPILE_CHECK(fn, val, res)                                     \
     do {                                                                \
-        typeof(fn(val)) real = fn(val);                                 \
+        typeof((fn)(val)) real = (fn)(val);                             \
                                                                         \
         if ( !__builtin_constant_p(real) )                              \
             asm ( ".error \"'" STR(fn(val)) "' not compile-time constant\"" ); \
-        else if ( real != res )                                         \
+        else if ( real != (res) )                                       \
             asm ( ".error \"Compile time check '" STR(fn(val) == res) "' failed\"" ); \
     } while ( 0 )
 #else
@@ -37,9 +37,9 @@
  */
 #define RUNTIME_CHECK(fn, val, res)                     \
     do {                                                \
-        typeof(fn(val)) real = fn(HIDE(val));           \
+        typeof((fn)(val)) real = (fn)(HIDE(val));       \
                                                         \
-        if ( real != res )                              \
+        if ( real != (res) )                            \
             panic("%s: %s(%s) expected %u, got %u\n",   \
                   __func__, #fn, #val, real, res);      \
     } while ( 0 )
-- 
2.34.1

[XEN PATCH 3/6] xen/guest_access: address violations of MISRA rule 20.7

[Nicola Vetrini]

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@bugseng.com>
---
 xen/include/xen/guest_access.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/include/xen/guest_access.h b/xen/include/xen/guest_access.h
index af33ae3ab652..8bd2a124e823 100644
--- a/xen/include/xen/guest_access.h
+++ b/xen/include/xen/guest_access.h
@@ -49,9 +49,9 @@
     ((XEN_GUEST_HANDLE(type)) { &(hnd).p->fld })
 
 #define guest_handle_from_ptr(ptr, type)        \
-    ((XEN_GUEST_HANDLE_PARAM(type)) { (type *)ptr })
+    ((XEN_GUEST_HANDLE_PARAM(type)) { (type *)(ptr) })
 #define const_guest_handle_from_ptr(ptr, type)  \
-    ((XEN_GUEST_HANDLE_PARAM(const_##type)) { (const type *)ptr })
+    ((XEN_GUEST_HANDLE_PARAM(const_##type)) { (const type *)(ptr) })
 
 /*
  * Copy an array of objects to guest context via a guest handle,
-- 
2.34.1

[XEN PATCH 4/6] x86emul: address violations of MISRA C Rule 20.7

[Nicola Vetrini]

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@bugseng.com>
---
These local helpers could in principle be deviated, but the readability
and functionality are essentially unchanged by complying with the rule,
so I decided to modify the macro definition as the preferred option.
---
 xen/arch/x86/x86_emulate/x86_emulate.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/x86_emulate/x86_emulate.c b/xen/arch/x86/x86_emulate/x86_emulate.c
index 2d5c1de8ecc2..9352d341346a 100644
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -2255,7 +2255,7 @@ x86_emulate(
         switch ( modrm_reg & 7 )
         {
 #define GRP2(name, ext) \
-        case ext: \
+        case (ext): \
             if ( ops->rmw && dst.type == OP_MEM ) \
                 state->rmw = rmw_##name; \
             else \
@@ -8611,7 +8611,7 @@ int x86_emul_rmw(
             unsigned long dummy;
 
 #define XADD(sz, cst, mod) \
-        case sz: \
+        case (sz): \
             asm ( "" \
                   COND_LOCK(xadd) " %"#mod"[reg], %[mem]; " \
                   _POST_EFLAGS("[efl]", "[msk]", "[tmp]") \
-- 
2.34.1

[XEN PATCH 5/6] x86/irq: address violations of MISRA C Rule 20.7

[Nicola Vetrini]

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@bugseng.com>
---
Note that the rule does not apply to f because that parameter
is not used as an expression in the macro, but rather as an identifier.
---
 xen/include/xen/irq.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/include/xen/irq.h b/xen/include/xen/irq.h
index adf33547d25f..0401f06c4fca 100644
--- a/xen/include/xen/irq.h
+++ b/xen/include/xen/irq.h
@@ -178,7 +178,7 @@ extern struct pirq *pirq_get_info(struct domain *d, int pirq);
 
 #define pirq_field(d, p, f, def) ({ \
     const struct pirq *__pi = pirq_info(d, p); \
-    __pi ? __pi->f : def; \
+    __pi ? __pi->f : (def); \
 })
 #define pirq_to_evtchn(d, pirq) pirq_field(d, pirq, evtchn, 0)
 #define pirq_masked(d, pirq) pirq_field(d, pirq, masked, 0)
-- 
2.34.1

[XEN PATCH 6/6] automation/eclair_analysis: clean ECLAIR configuration scripts

[Nicola Vetrini]

Remove from the ECLAIR integration scripts an unused option, which
was already ignored, and make the help texts consistent
with the rest of the scripts.

No functional change.

Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
---
 automation/eclair_analysis/ECLAIR/analyze.sh | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/automation/eclair_analysis/ECLAIR/analyze.sh b/automation/eclair_analysis/ECLAIR/analyze.sh
index 0ea5520c93a6..e96456c3c18d 100755
--- a/automation/eclair_analysis/ECLAIR/analyze.sh
+++ b/automation/eclair_analysis/ECLAIR/analyze.sh
@@ -11,7 +11,7 @@ fatal() {
 }
 
 usage() {
-  fatal "Usage: ${script_name} <ARM64|X86_64> <Set0|Set1|Set2|Set3>"
+  fatal "Usage: ${script_name} <ARM64|X86_64> <accepted|monitored>"
 }
 
 if [[ $# -ne 2 ]]; then
@@ -40,7 +40,6 @@ ECLAIR_REPORT_LOG=${ECLAIR_OUTPUT_DIR}/REPORT.log
 if [[ "$1" = "X86_64" ]]; then
   export CROSS_COMPILE=
   export XEN_TARGET_ARCH=x86_64
-  EXTRA_ECLAIR_ENV_OPTIONS=-disable=MC3R1.R20.7
 elif [[ "$1" = "ARM64" ]]; then
   export CROSS_COMPILE=aarch64-linux-gnu-
   export XEN_TARGET_ARCH=arm64
-- 
2.34.1

Re: [XEN PATCH 2/6] xen/self-tests: address violations of MISRA rule 20.7

[Jan Beulich]

On 11.06.2024 17:53, 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@bugseng.com>
> ---
> In this case the use of parentheses can detect misuses of the COMPILE_CHECK
> macro for the fn argument that happen to pass the compile-time check
> (see e.g. https://godbolt.org/z/n4zTdz595).

While readability suffers a little, I'm okay with the approach taken:
Reviewed-by: Jan Beulich <jbeulich@suse.com>
I'd like to give in particular Andrew some time to possibly object, though.
And anyway I don't think we want to rush any more Misra changes into 4.19.

Jan

Re: [XEN PATCH 3/6] xen/guest_access: address violations of MISRA rule 20.7

[Jan Beulich]

On 11.06.2024 17:53, 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@bugseng.com>

Acked-by: Jan Beulich <jbeulich@suse.com>

Re: [XEN PATCH 4/6] x86emul: address violations of MISRA C Rule 20.7

[Jan Beulich]

On 11.06.2024 17:53, 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@bugseng.com>
> ---
> These local helpers could in principle be deviated, but the readability
> and functionality are essentially unchanged by complying with the rule,
> so I decided to modify the macro definition as the preferred option.

Well, yes, but ...

> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -2255,7 +2255,7 @@ x86_emulate(
>          switch ( modrm_reg & 7 )
>          {
>  #define GRP2(name, ext) \
> -        case ext: \
> +        case (ext): \
>              if ( ops->rmw && dst.type == OP_MEM ) \
>                  state->rmw = rmw_##name; \
>              else \
> @@ -8611,7 +8611,7 @@ int x86_emul_rmw(
>              unsigned long dummy;
>  
>  #define XADD(sz, cst, mod) \
> -        case sz: \
> +        case (sz): \
>              asm ( "" \
>                    COND_LOCK(xadd) " %"#mod"[reg], %[mem]; " \
>                    _POST_EFLAGS("[efl]", "[msk]", "[tmp]") \

... this is really nitpicky of the rule / tool. What halfway realistic
ways do you see to actually misuse these macros? What follows the "case"
keyword is just an expression; no precedence related issues are possible.

Jan

Re: [XEN PATCH 5/6] x86/irq: address violations of MISRA C Rule 20.7

[Jan Beulich]

On 11.06.2024 17:53, 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@bugseng.com>

Acked-by: Jan Beulich <jbeulich@suse.com>

Re: [XEN PATCH 4/6] x86emul: address violations of MISRA C Rule 20.7

[Nicola Vetrini]

On 2024-06-12 11:19, Jan Beulich wrote:
> On 11.06.2024 17:53, 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@bugseng.com>
>> ---
>> These local helpers could in principle be deviated, but the 
>> readability
>> and functionality are essentially unchanged by complying with the 
>> rule,
>> so I decided to modify the macro definition as the preferred option.
> 
> Well, yes, but ...
> 
>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
>> @@ -2255,7 +2255,7 @@ x86_emulate(
>>          switch ( modrm_reg & 7 )
>>          {
>>  #define GRP2(name, ext) \
>> -        case ext: \
>> +        case (ext): \
>>              if ( ops->rmw && dst.type == OP_MEM ) \
>>                  state->rmw = rmw_##name; \
>>              else \
>> @@ -8611,7 +8611,7 @@ int x86_emul_rmw(
>>              unsigned long dummy;
>> 
>>  #define XADD(sz, cst, mod) \
>> -        case sz: \
>> +        case (sz): \
>>              asm ( "" \
>>                    COND_LOCK(xadd) " %"#mod"[reg], %[mem]; " \
>>                    _POST_EFLAGS("[efl]", "[msk]", "[tmp]") \
> 
> ... this is really nitpicky of the rule / tool. What halfway realistic
> ways do you see to actually misuse these macros? What follows the 
> "case"
> keyword is just an expression; no precedence related issues are 
> possible.
> 

I do share the view: no real danger is possible in sensible uses. Often 
MISRA rules are stricter than necessary to have a simple formulation, by 
avoiding too many special cases.

However, if a deviation is formulated, then it needs to be maintained, 
for no real readability benefit in this case, in my opinion. I can be 
convinced otherwise, of course.

-- 
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)

Re: [XEN PATCH 4/6] x86emul: address violations of MISRA C Rule 20.7

[Jan Beulich]

On 12.06.2024 11:52, Nicola Vetrini wrote:
> On 2024-06-12 11:19, Jan Beulich wrote:
>> On 11.06.2024 17:53, 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@bugseng.com>
>>> ---
>>> These local helpers could in principle be deviated, but the 
>>> readability
>>> and functionality are essentially unchanged by complying with the 
>>> rule,
>>> so I decided to modify the macro definition as the preferred option.
>>
>> Well, yes, but ...
>>
>>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
>>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
>>> @@ -2255,7 +2255,7 @@ x86_emulate(
>>>          switch ( modrm_reg & 7 )
>>>          {
>>>  #define GRP2(name, ext) \
>>> -        case ext: \
>>> +        case (ext): \
>>>              if ( ops->rmw && dst.type == OP_MEM ) \
>>>                  state->rmw = rmw_##name; \
>>>              else \
>>> @@ -8611,7 +8611,7 @@ int x86_emul_rmw(
>>>              unsigned long dummy;
>>>
>>>  #define XADD(sz, cst, mod) \
>>> -        case sz: \
>>> +        case (sz): \
>>>              asm ( "" \
>>>                    COND_LOCK(xadd) " %"#mod"[reg], %[mem]; " \
>>>                    _POST_EFLAGS("[efl]", "[msk]", "[tmp]") \
>>
>> ... this is really nitpicky of the rule / tool. What halfway realistic
>> ways do you see to actually misuse these macros? What follows the 
>> "case"
>> keyword is just an expression; no precedence related issues are 
>> possible.
>>
> 
> I do share the view: no real danger is possible in sensible uses. Often 
> MISRA rules are stricter than necessary to have a simple formulation, by 
> avoiding too many special cases.
> 
> However, if a deviation is formulated, then it needs to be maintained, 
> for no real readability benefit in this case, in my opinion. I can be 
> convinced otherwise, of course.

Well, aiui you're thinking of a per-macro deviation here. Whereas I'd be
thinking of deviating the pattern.

Jan

Re: [XEN PATCH 4/6] x86emul: address violations of MISRA C Rule 20.7

[Nicola Vetrini]

On 2024-06-12 12:36, Jan Beulich wrote:
> On 12.06.2024 11:52, Nicola Vetrini wrote:
>> On 2024-06-12 11:19, Jan Beulich wrote:
>>> On 11.06.2024 17:53, 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@bugseng.com>
>>>> ---
>>>> These local helpers could in principle be deviated, but the
>>>> readability
>>>> and functionality are essentially unchanged by complying with the
>>>> rule,
>>>> so I decided to modify the macro definition as the preferred option.
>>> 
>>> Well, yes, but ...
>>> 
>>>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
>>>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
>>>> @@ -2255,7 +2255,7 @@ x86_emulate(
>>>>          switch ( modrm_reg & 7 )
>>>>          {
>>>>  #define GRP2(name, ext) \
>>>> -        case ext: \
>>>> +        case (ext): \
>>>>              if ( ops->rmw && dst.type == OP_MEM ) \
>>>>                  state->rmw = rmw_##name; \
>>>>              else \
>>>> @@ -8611,7 +8611,7 @@ int x86_emul_rmw(
>>>>              unsigned long dummy;
>>>> 
>>>>  #define XADD(sz, cst, mod) \
>>>> -        case sz: \
>>>> +        case (sz): \
>>>>              asm ( "" \
>>>>                    COND_LOCK(xadd) " %"#mod"[reg], %[mem]; " \
>>>>                    _POST_EFLAGS("[efl]", "[msk]", "[tmp]") \
>>> 
>>> ... this is really nitpicky of the rule / tool. What halfway 
>>> realistic
>>> ways do you see to actually misuse these macros? What follows the
>>> "case"
>>> keyword is just an expression; no precedence related issues are
>>> possible.
>>> 
>> 
>> I do share the view: no real danger is possible in sensible uses. 
>> Often
>> MISRA rules are stricter than necessary to have a simple formulation, 
>> by
>> avoiding too many special cases.
>> 
>> However, if a deviation is formulated, then it needs to be maintained,
>> for no real readability benefit in this case, in my opinion. I can be
>> convinced otherwise, of course.
> 
> Well, aiui you're thinking of a per-macro deviation here. Whereas I'd 
> be
> thinking of deviating the pattern.
> 

Might be reasonable. I'll think about it for v2

-- 
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)