[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v3] misra: consider conversion from UL or (void*) to function pointer as safe


  • To: Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>
  • From: Dmytro Prokopchuk1 <dmytro_prokopchuk1@xxxxxxxx>
  • Date: Thu, 23 Oct 2025 10:00:13 +0000
  • Accept-language: en-US, uk-UA, ru-RU
  • 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=rabsGKobnCa5JgieRN6iv6k9/C+gcZ/PhdNVSQvyyQk=; b=hQzRqaGIp2OvqwFtxaiQupn4Bx9el11TcumHxD3NwYB3jygHWNOgI2qaAP0u+L39t4MeAOyl1HkfVE+0gEEzVF8/rvj8vklWM8LYqfbgUz/cH4aT8RN7ii0QjVZV1KQSBWiL14VVRKQudaW/SJuXOI+JvoFd4vJ8TjQlHkg18EauAnzycwO1BQrvGeIVCNoa/tTNrRA4cmn62zTZt8no0QXnoPHYdjIZXdyWH3aTP9OUW0Pk4a82jHVbUWz4fwbpJNxOKf0uhG1pG+cyCLUZLsbPxjuUyyzmyVD0/yW9ynprfjZcGIDvhDr3RiVkgC4pxvamVyYH/uICfdrwGhYWVg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=IUeDHJCMW7W6IPZKHiF35XcdESvOJCzgJEUc9B64d+sAcaw0lMArrT6YmOICNpEJZQsvmyQxAuIXPcc5EyjFf/7EK0NFrP5kVcAwTzBiLQhrmYLG3jJz0k6++4d7b7OawY3Lf1Gb6ETqp0tf96D0nkk/Wgm9lAY4LB9nrSNzOs8tprt/iv8BNkcluwZuQvmi3UNSQ+pXF5qFbLHJ+IKF1kFIHsGIioBgKgGQc7Cb6eFjna3ddw3bTvPvef9X2fyS9bDbpNog3yW6RkzPhP1Bz6gUQzJYKP6y+blNINyTyEw14CO1wDLTvlHkO2dLonhMWNM4jGID2lJmy9iCPcKHcA==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com;
  • Cc: Doug Goldstein <cardoe@xxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, Michal Orzel <michal.orzel@xxxxxxx>, Julien Grall <julien@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Thu, 23 Oct 2025 10:00:31 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHcPSX2fWa1eZv9x0mRzqs7fz2kjrTCvSwAgAMyXQCACZ3PAA==
  • Thread-topic: [PATCH v3] misra: consider conversion from UL or (void*) to function pointer as safe


On 10/17/25 10:09, Nicola Vetrini wrote:
> On 2025-10-15 08:20, Jan Beulich wrote:
>> On 14.10.2025 18:16, Dmytro Prokopchuk1 wrote:
>>> --- a/xen/common/version.c
>>> +++ b/xen/common/version.c
>>> @@ -217,6 +217,20 @@ void __init xen_build_init(void)
>>>  #endif /* CONFIG_X86 */
>>>  }
>>>  #endif /* BUILD_ID */
>>> +
>>> +#if defined(__i386__) || defined(__x86_64__) || defined(__arm__) || 
>>> defined(__aarch64__)
>>
>> Why __i386__? Also (nit): Line too long.

Well, I copied this line from Xen codebase,
but yeah, __i386__ is outdated now.
I'll remove it.

>>
>> And why this restriction without any comment here or ...
>>
>>> +static void __init __maybe_unused build_assertions(void)
>>> +{
>>> +    /*
>>> +     * To confirm conversion compatibility between unsigned long, 
>>> (void *)
>>> +     * and function pointers for X86 and ARM architectures only.
>>
>> ... explanation here? More generally - how would people know to update
>> the condition if another port was to be certified?
>>
>> Finally, with the v3 addition here, is Nicola's R-b really still 
>> applicable?
>>
> 
> I agree with the point you make about i386 (e.g., C-language- 
> toolchain.rst may be mentioned to provide some context about the 
> preprocessor guard); that said, my R-by can be retained
> 
>> Jan
>>
>>> +     */
>>> +
>>> +    BUILD_BUG_ON(sizeof(unsigned long) != sizeof(void (*)(void)));
>>> +    BUILD_BUG_ON(sizeof(void *) != sizeof(void (*)(void)));
>>> +}
>>> +#endif
>>> +
>>>  /*
>>>   * Local variables:
>>>   * mode: C
> 

And probably v4 can have the following wording:

/*
  * This assertion checks compatibility between 'unsigned long', 'void *',
  * and function pointers. This is true for X86 (x86_64) and ARM (arm, 
aarch64)
  * architectures, which is why the check is restricted to these.
  *
  * For more context on architecture-specific preprocessor guards, see
  * docs/misc/C-language-toolchain.rst.
  *
  * If Xen is ported to a new architecture, verify that this 
compatibility holds
  * before adding its macro to the condition below. If the compatibility 
does not
  * hold, this assertion may need to be revised or removed for that 
architecture.
  */

BR, Dmytro.

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.