| Message ID | d2bc16c1b2d00b85f4b1a96bd855bbfe38861e87.1710762555.git.nicola.vetrini@bugseng.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | address some violations of MISRA C Rule 20.7 | expand |
On 18.03.2024 12: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> > --- > This file is matched by exclude-list.json, but the fix is rather trivial > and impacts code that in under the scope of MISRA compliance. On the same basis as the other change: Acked-by: Jan Beulich <jbeulich@suse.com> I wonder though: Where do we draw the line? Jan
On 2024-03-18 17:49, Jan Beulich wrote: > On 18.03.2024 12: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> >> --- >> This file is matched by exclude-list.json, but the fix is rather >> trivial >> and impacts code that in under the scope of MISRA compliance. > > On the same basis as the other change: > Acked-by: Jan Beulich <jbeulich@suse.com> > Thanks. > I wonder though: Where do we draw the line? > > Jan So far the policy, at least from my side, has been to submit a patch if the change is simple enough, to avoid adding a special case that needs to be documented and maintained. In case concerns were raised, propose a deviation and follow up from there.
diff --git a/xen/arch/arm/include/asm/arm64/efibind.h b/xen/arch/arm/include/asm/arm64/efibind.h index f13eadd4f0ab..a1323d452e2e 100644 --- a/xen/arch/arm/include/asm/arm64/efibind.h +++ b/xen/arch/arm/include/asm/arm64/efibind.h @@ -22,9 +22,9 @@ Revision History #pragma pack() #endif -#define EFIERR(a) (0x8000000000000000ULL | a) +#define EFIERR(a) (0x8000000000000000ULL | (a)) #define EFI_ERROR_MASK 0x8000000000000000ULL -#define EFIERR_OEM(a) (0xc000000000000000ULL | a) +#define EFIERR_OEM(a) (0xc000000000000000ULL | (a)) #define BAD_POINTER 0xFBFBFBFBFBFBFBFBULL #define MAX_ADDRESS 0xFFFFFFFFFFFFFFFFULL diff --git a/xen/arch/x86/include/asm/x86_64/efibind.h b/xen/arch/x86/include/asm/x86_64/efibind.h index e23cd16cb6a0..28bc18c24bb3 100644 --- a/xen/arch/x86/include/asm/x86_64/efibind.h +++ b/xen/arch/x86/include/asm/x86_64/efibind.h @@ -117,9 +117,9 @@ typedef uint64_t UINTN; #endif #endif -#define EFIERR(a) (0x8000000000000000 | a) +#define EFIERR(a) (0x8000000000000000 | (a)) #define EFI_ERROR_MASK 0x8000000000000000 -#define EFIERR_OEM(a) (0xc000000000000000 | a) +#define EFIERR_OEM(a) (0xc000000000000000 | (a)) #define BAD_POINTER 0xFBFBFBFBFBFBFBFB
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> --- This file is matched by exclude-list.json, but the fix is rather trivial and impacts code that in under the scope of MISRA compliance. --- xen/arch/arm/include/asm/arm64/efibind.h | 4 ++-- xen/arch/x86/include/asm/x86_64/efibind.h | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-)