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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 22.09.2026 12:57, Volodymyr Babchuk wrote:
> Jan Beulich <jbeulich@xxxxxxxx> writes:
>> On 22.09.2026 03:38, Volodymyr Babchuk wrote:
>>> Jan Beulich <jbeulich@xxxxxxxx> 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
> 
> Well, that was unexpected. Talk about principle of least surprise...
> 
>> The only alternative I see (somewhat more risky overall) would be to
>> introduce
>>
>> #define acpi_uintptr_t                  uintptr_t
> 
> What are the risks? I'd really prefer to have fewer gotchas in the code.

It hides casting away of const-ness. Right here we would like that, yet in
the general case I think we don't. Otoh Linux switched to the above in the
5.18 dev cycle.

Jan