[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [XEN PATCH v2 12/13] xen/x86: fix violations of MISRA C:2012 Rule 7.2
- To: Simone Ballarin <simone.ballarin@xxxxxxxxxxx>
- From: Jan Beulich <jbeulich@xxxxxxxx>
- Date: Fri, 7 Jul 2023 09:04:04 +0200
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; 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=ujUusuhvPdDFcgfLM/kUUf9W850npxb8SCXzCPUx2E8=; b=jitvkaAtY0MHyej+YmfkocWztzuR+/1szYyV/hK9H+v6i9f7w/JYayLsOOAvEyLiaFE3YMNzHcBZr8agIwe+aDURsX2GkM7HPG8ljK8hDoWLPAMn9YWrG5COjJhq9J1TF4GeFvdXBu6nNKzTQqb/q3MPOCkQUOdvOivdxP2LeibXq2LqV337xnoaig2NKC8i+SeBYaU24any+yAL0GSGtahzUwHef89D9J8Zr4IytQKIJ1C/4hkF1kYor9CvzoImYh7XIKT1Fq2NFsXtAEMSVD9ae76gure6CiHzagYPYnAWd9CeMXJVxBL+h7dahNsFxyYwNXRsRX/6kmdLLRBiwQ==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HoWf2a6FGDWTEcrvg5rJ4Fyan3EVxxIms/2yMBNxvWrIP4F0aW5x+T44ZTYvG7uGXvjvVUQivIjOmqXg3GJH33JVn1aaC1BcLpKaBEVTRXXcP5QXNEwADGVdSHC2np55z2miBSJj7UHcewh7T7wsGlUV4cH2EQxp9Xs72O5hdR6DB1dv9+0UxDeE7ZnP2CBoJ1jk5bar6yn+OwsnYguDgn3qjoMRqpAJNbWw3/qrgSlcwG7TMFOEyRPsRZVbYIICq+/ZZMq1ONrQdnJmJCHpsAt5gLWTrC+1a9g+UVU2tkKZWu6uH7IgXiejPgn6G5UGlcCeNlS4oOp9wtHXd1ci9w==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
- Cc: consulting@xxxxxxxxxxx, Gianluca Luparini <gianluca.luparini@xxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Paul Durrant <paul@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Michal Orzel <michal.orzel@xxxxxxx>, Xenia Ragiadakou <Xenia.Ragiadakou@xxxxxxx>, Ayan Kumar Halder <ayan.kumar.halder@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
- Delivery-date: Fri, 07 Jul 2023 07:04:37 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 07.07.2023 08:50, Simone Ballarin wrote:
> Il giorno gio 6 lug 2023 alle ore 18:22 Jan Beulich <jbeulich@xxxxxxxx> ha
> scritto:
>
>> On 06.07.2023 18:08, Simone Ballarin wrote:
>>> Il giorno gio 6 lug 2023 alle ore 10:26 Jan Beulich <jbeulich@xxxxxxxx>
>> ha
>>> scritto:
>>>
>>>> On 05.07.2023 17:26, Simone Ballarin wrote:
>>>>> --- a/xen/arch/x86/apic.c
>>>>> +++ b/xen/arch/x86/apic.c
>>>>> @@ -1211,7 +1211,7 @@ static void __init calibrate_APIC_clock(void)
>>>>> * Setup the APIC counter to maximum. There is no way the lapic
>>>>> * can underflow in the 100ms detection time frame.
>>>>> */
>>>>> - __setup_APIC_LVTT(0xffffffff);
>>>>> + __setup_APIC_LVTT(0xffffffffU);
>>>>
>>>> While making the change less mechanical, we want to consider to switch
>>>> to ~0 in this and similar cases.
>>>>
>>>
>>> Changing ~0U is more than not mechanical: it is possibly dangerous.
>>> The resulting value could be different depending on the architecture,
>>> I prefer to not make such kind of changes in a MISRA-related patch.
>>
>> What do you mean by "depending on the architecture", when this is
>> x86-only code _and_ you can check what type parameter the called
>> function has?
>
> Ok, I will change these literals in ~0U in the next submission.
Except that I specifically meant ~0, not ~0U. We mean "maximum value"
here, and at the call site it doesn't matter how wide the function
parameter's type is. If it was 64-bit, ~0U would not do what is wanted.
Jan
|
