Re: [PATCH v2] xen/decompress: resolve MISRA R5.5 identifier/macro name conflicts

[Jan Beulich <jbeulich@xxxxxxxx>]

On 24.05.2026 22:25, Dmytro Prokopchuk1 wrote:
> Convert 'free' macro in 'decompress.h' from object-like to function-like
> form.
> 
> The object-like macro '#define free xfree' performs unconditional text
> replacement, causing conflicts with identifiers named 'free', such as
> struct fields in 'page_info' unions defined in 
> 'xen/arch/arm/include/asm/mm.h'.
> Function-like macros only match when followed by parentheses, allowing
> 'free' to be used both as a macro and as a struct field without conflicts.
> 
> Applying function-like form to 'malloc', 'large_malloc' and 'large_free'
> ensures consistent macro style.

Hmm, are you sure things are consistent now? (See bottom.)

> Function-like macros also intentionally prevent uses where the underlying
> function identifier is needed directly, such as taking a function pointer.

Why "intentionally"? I rather view this as a generally unwanted effect,
merely acceptable here due to ...

> No such uses exist in the current Xen codebase.

... this. IOW I'd suggest to re-word the paragraph to

"While function-like macros prevent uses where the underlying function
 identifier is needed directly, such as taking a function pointer, no
 such uses exist in the current Xen codebase."

> Signed-off-by: Dmytro Prokopchuk <dmytro_prokopchuk1@xxxxxxxx>

Acked-by: Jan Beulich <jbeulich@xxxxxxxx>
with ...

> --- a/xen/common/decompress.h
> +++ b/xen/common/decompress.h
> @@ -9,11 +9,11 @@
>  #include <xen/types.h>
>  #include <xen/xmalloc.h>
>  
> -#define malloc xmalloc_bytes
> -#define free xfree
> +#define malloc(a) xmalloc_bytes(a)
> +#define free(a) xfree(a)
>  
> -#define large_malloc xmalloc_bytes
> -#define large_free xfree
> +#define large_malloc(a) xmalloc_bytes(a)
> +#define large_free(a) xfree(a)
>  
>  #else

... the two macros down from here also adjusted accordingly. Or
alternatively (maybe even better, as that's reducing redundancy) with
large_{malloc,free}() moved past the #endif.

Could I additionally talk you into naming the macro parameters closer to
what they actually represent (e.g. "s" for malloc() and "p" for free())?

Jan