Re: [PATCH 09/14] ACPI: address a Misra rule 11.8 violation in Arm code

[Jan Beulich <jbeulich@suse.com>]

On 22.09.2026 03:38, Volodymyr Babchuk wrote:
> Jan Beulich <jbeulich@suse.com> writes:
>> Outside of drivers/acpi/tables/ (which is excluded from Eclair reporting
>> for dubious reasons), arch/arm/acpi/domain_build.c is the only user of
>> ACPI_COMPARE_NAME(). Make the macro const correct, at the expense of
>> introducing a "const" variant of ACPI_CAST_PTR(), and at the expense of
> 
> I think you can avoid adding ACPI_CAST_PTR() by providing a const
> type. Like this:
> 
> +#define ACPI_COMPARE_NAME(a, b)         (*ACPI_CAST_PTR (const u32, a) == \
> +                                         *ACPI_CAST_PTR (const u32, b))

I don't think so. You did notice ...

>> --- a/xen/include/acpi/acmacros.h
>> +++ b/xen/include/acpi/acmacros.h
>> @@ -103,6 +103,7 @@
>>   * Pointer manipulation
>>   */
>>  #define ACPI_CAST_PTR(t, p)             ((t *) (acpi_uintptr_t) (p))
>> +#define ACPI_CAST_CPTR(t, p)            ((const t *) (const acpi_uintptr_t) (p))

... this, I assume. On the surface it looks odd, because one would expect
acpi_uintptr_t to be a scalar type, like uintptr_t is. But it isn't:

#ifndef acpi_uintptr_t
#define acpi_uintptr_t                  void *
#endif

The only alternative I see (somewhat more risky overall) would be to
introduce

#define acpi_uintptr_t                  uintptr_t

in acpi/platform/aclinux.h (or, imo less desirable, acpi/platform/acenv.h).

Then what you suggest would no longer cast away const-ness at any of the
individual casting steps.

Jan