| Message ID | 2d3842a990189c37fa12672994b779ad42975235.1711118582.git.nicola.vetrini@bugseng.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | address some violations of MISRA C Rule 20.7 | expand |
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.vetrini@bugseng.com> Seeing this is again touching an imported header, we finally need to settle on where to draw the line. The way this is going is that you're proposing many small changes which individually all look "small enough". Yet when doing so for long enough, the entire header may end up different from its original. Jan > --- a/xen/include/efi/efiapi.h > +++ b/xen/include/efi/efiapi.h > @@ -63,7 +63,8 @@ EFI_STATUS > OUT UINT32 *DescriptorVersion > ); > > -#define NextMemoryDescriptor(Ptr,Size) ((EFI_MEMORY_DESCRIPTOR *) (((UINT8 *) Ptr) + Size)) > +#define NextMemoryDescriptor(Ptr,Size) ((EFI_MEMORY_DESCRIPTOR *) \ > + ((UINT8 *)(Ptr) + (Size))) > > > typedef
On 2024-03-25 10:25, 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.vetrini@bugseng.com> > > Seeing this is again touching an imported header, we finally need to > settle > on where to draw the line. The way this is going is that you're > proposing > many small changes which individually all look "small enough". Yet when > doing so for long enough, the entire header may end up different from > its > original. > > Jan > Ok, if you feel that these (and possibly others) are too many, then I'll leave xen/include/efi/* alone and deviate those violations resulting from the use of these macros in files that are in scope. I don't think there are others from imported headers outside efi, but I'm not 100% sure. >> --- a/xen/include/efi/efiapi.h >> +++ b/xen/include/efi/efiapi.h >> @@ -63,7 +63,8 @@ EFI_STATUS >> OUT UINT32 *DescriptorVersion >> ); >> >> -#define NextMemoryDescriptor(Ptr,Size) ((EFI_MEMORY_DESCRIPTOR *) >> (((UINT8 *) Ptr) + Size)) >> +#define NextMemoryDescriptor(Ptr,Size) ((EFI_MEMORY_DESCRIPTOR *) \ >> + ((UINT8 *)(Ptr) + (Size))) >> >> >> typedef
diff --git a/xen/include/efi/efiapi.h b/xen/include/efi/efiapi.h index a616d1238aa4..6d4d4e340d9e 100644 --- a/xen/include/efi/efiapi.h +++ b/xen/include/efi/efiapi.h @@ -63,7 +63,8 @@ EFI_STATUS OUT UINT32 *DescriptorVersion ); -#define NextMemoryDescriptor(Ptr,Size) ((EFI_MEMORY_DESCRIPTOR *) (((UINT8 *) Ptr) + Size)) +#define NextMemoryDescriptor(Ptr,Size) ((EFI_MEMORY_DESCRIPTOR *) \ + ((UINT8 *)(Ptr) + (Size))) typedef
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/efi/efiapi.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)