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

[Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>]

Hi Jan,

Sorry for the late reply

Jan Beulich <jbeulich@xxxxxxxx> writes:

> 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.

... but for different reason. clang complained about pointer
subtraction with a null pointer. This does not fired in Xen because we
are not using ACPI_PTR_DIFF() yet. But, if we are going to use it, we'll
face the same problem.

So, if we are already touching this parts, maybe it is better port that
Linux patch ([1]) and use const types as I suggested?


[1] https://lore.kernel.org/linux-acpi/20210927121338.938994-1-arnd@xxxxxxxxxx, 

-- 
WBR, Volodymyr