[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 09/14] ACPI: address a Misra rule 11.8 violation in Arm code
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>
- Date: Tue, 22 Sep 2026 10:57:21 +0000
- Accept-language: en-US
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=uaOefTgiUQBwZzauMDtdjPiXvVgb18Z1289qApiz8uk=; b=vXpvtHkAl4tXYe1j11kG8yuT3eIX5Exkj+twNOGO7NCMLRfMD+vYRbmlsq0eqknTZj0oqMZwKv9e0q82rZRelZSWxTlg6kYGHX33YnL2dkzJN2NHAbt9Hz7bXHhQxykNdxu+NEBrsaDmZVXGF2KCAmRAUWzrXA7UrYD80vAT+/6Cb8Sh5KuPg+mimvzMN2NZlGOgvrIVarGOeL5uTcS995tHLzlS1w1AATb+ZEpHhBNfsxejsm+PR2K0Ms/uHEruITJmFcYZ0XJpPlGlW3JownmiRP1xMtmnCcd3zIRxttaBfyjMPBNfHsZEJvfol40zz8JEOoJcf76wNONFE69TPg==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=QYt6ukm3+hA4xe+h2s3UNMypxsI2Hx80Xju2eR/E2st0urD7ubWmv8EqcKkPrkdsvD9oq5Qx0KQ9FrKtYFhxbkmLYS2UAFIQsgoid3GZTBAmIhytUPdvAPVOJPAfSNJUavO47wBVGlDqxTS3GB+L7qTxutb7LPIPJJp0nuUUhCNDDlMMaCLu+MOG0ikTpvwlSc558vD6b+xUGIkbku1JdiKDtRgh33i+yCJLuRx8bRyhoXVvkHXEZWHNasp5AnrUkbMErpTX6EkgqY+sRx+cC8jL5OeKWBGa39k6k62l8a9K+AgPNH15AEaMv9o+77ad3hJj/MHiSu1kpClfzgXoYA==
- Authentication-results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck"
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com;
- Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, Michal Orzel <michal.orzel@xxxxxxx>, Roger Pau Monné <roger@xxxxxxxxxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>
- Delivery-date: Tue, 22 Sep 2026 10:57:33 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
- Thread-index: AQHdOqUePUfY0zBPU0K0F/hx5odMHA==
- Thread-topic: [PATCH 09/14] ACPI: address a Misra rule 11.8 violation in Arm code
Hi Jan,
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.
--
WBR, Volodymyr
|
