[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 0/9] MISRA C 2012 8.1 rule fixes
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: Bertrand Marquis <Bertrand.Marquis@xxxxxxx>
- Date: Wed, 22 Jun 2022 14:27:37 +0000
- Accept-language: en-GB, en-US
- Arc-authentication-results: i=2; mx.microsoft.com 1; spf=temperror (sender ip is 63.35.35.123) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=arm.com; dmarc=temperror action=none header.from=arm.com; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com] dmarc=[1,1,header.from=arm.com])
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none
- Arc-message-signature: i=2; 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=SiT9BcoUKho+AnERVhlqd+nwbS3V+UP3nk5M87Uf6Zs=; b=M6/BY9IYS7YuZuE6uMZiH9s97iF6iCfoylTMqGAI0nYB7VGhmvxiGx70lOlBMHb41QDXARox78SHiE4538k7Ccx4aAq8Q42gkALYwPvLtk1byDxVqWKSziBDuxOzl0S5TUsaz/gyWE/6KlUeNvt+agyjdaG0RJIGYSsSbEdnIMqEQyJ6R7XGUhZDGnew/y824Qyb/phwa1Wx6CSQkdyVVia4cX2rIOsxTY1MqLgnvw/Q2xWZXmmK1SxI7ZYmFWDu/AaiNX8i1ReTJC0mARyw7ZRWwBVP6+kUunVn+ezg4reTBCmZEHJeOWty3I6k1CfLK4eqBCgbUkZfVmj8j3+gYA==
- 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=SiT9BcoUKho+AnERVhlqd+nwbS3V+UP3nk5M87Uf6Zs=; b=imE3dnwnsqL71yqRKWeSR6qjs7hyNcGT5PO8qnbhWQfdMVwvmZcFkRVBl7TcT80GScvkisotTnQbqmZjaJcX8oY7EHCUhttl+SotJsL/bWlZ+RaJcJUi0pHVoix0+B4271yg9A9J3buUKkKEHPQc0WJgJJOcB3DoKIZcIVZtC6sRp0rZeMdDA8jyJSkEjEJ2obmqHQkXlGe5aubA7WRzFtzGwAnvhhVOSVFLRVZAA9gSQtBu4scUsPRjzeQ3CyND+S/g6+YcdG3D8XerxEx+x373w1QRZ0huamxjM4j83Z0UMkjuyg7JnB/PPo+3yqYVJT4Ha/3JTbYv9ktA22Lxeg==
- Arc-seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass; b=W5HUAGPuKv+GArt5EYxmhGD+bi4QgtdNKAhqdycIfkhTHFBmPGOZW/JgKx+R0d8d86JgbpznvxQ/ozN+Vr4R/rSdII1R5u1GS/W2FyCctutu3xypMJ8KEG7y4C9Kjz8xLToreP+sKOjbQLvuv28E7lfXKo655DnSQuFPIpsHkn5DBvo1J5ks+rLVYdoxlp3GnnPAamyyT21zYB03lW5seaxZs3A4/V3wj1Yt96zLSPF5pjPl5tLqKZEK7cEmJqiLjp56khXBmvXF8mA4WzWEv6OhNXQOGTYwVkAd4jk+hCx/ykoneTMLH5SX96wYGsGTWTV/iJV/tx+0RnvBoFbXNA==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bxgYGzg1W0QptBhQmUHF6nvWXyXzpYHn4EsfmnuR72K6PMCSAAwLKNHrwvraRiwq/1Fsm0a5VDQaIxRZ1D/PUTZmnadGwC0JYlcg7GU035kcAsncGCPd2z0lFq3wxjm4sV4d7rl/6R8WF/XrTFdfWjp2c2HqDTSMKkb1mw0GHx0z3UqBjsRXWF5zyvY/QE8MQd9JNLQLNvthIJZAquNseN2pHWFRheMO7tuqogDJp+rl+3a7BwhZ4ABF/hvQB57P1ArCEblh/WKU4EiWaL4HlcRB4QyPdSngkSuHGD/kBgrPfKfxb8DSbzOJs4BWLYLLvhGyP5ePCbTD9OSt4okJKg==
- Authentication-results-original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
- Cc: Michal Orzel <Michal.Orzel@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Juergen Gross <jgross@xxxxxxxx>, Dario Faggioli <dfaggioli@xxxxxxxx>, Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>, "Daniel P. Smith" <dpsmith@xxxxxxxxxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- Delivery-date: Wed, 22 Jun 2022 14:28:05 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
- Nodisclaimer: true
- Original-authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
- Thread-index: AQHYhHPRZL4o3B5WdE6OPtXA3biXiq1bO8sAgAAqE4CAAAG+gIAADwQAgAAEMoCAAAS3gA==
- Thread-topic: [PATCH 0/9] MISRA C 2012 8.1 rule fixes
Hi,
> On 22 Jun 2022, at 15:10, Jan Beulich <jbeulich@xxxxxxxx> wrote:
>
> On 22.06.2022 15:55, Bertrand Marquis wrote:
>> Hi Jan,
>>
>>> On 22 Jun 2022, at 14:01, Jan Beulich <jbeulich@xxxxxxxx> wrote:
>>>
>>> On 22.06.2022 14:55, Michal Orzel wrote:
>>>> On 22.06.2022 12:25, Jan Beulich wrote:
>>>>> On 20.06.2022 09:02, Michal Orzel wrote:
>>>>>> This series fixes all the findings for MISRA C 2012 8.1 rule, reported by
>>>>>> cppcheck 2.7 with misra addon, for Arm (arm32/arm64 - target
>>>>>> allyesconfig).
>>>>>> Fixing this rule comes down to replacing implicit 'unsigned' with
>>>>>> explicit
>>>>>> 'unsigned int' type as there are no other violations being part of that
>>>>>> rule
>>>>>> in the Xen codebase.
>>>>>
>>>>> I'm puzzled, I have to admit. While I agree with all the examples in the
>>>>> doc, I notice that there's no instance of "signed" or "unsigned" there.
>>>>> Which matches my understanding that "unsigned" and "signed" on their own
>>>>> (just like "long") are proper types, and hence the omission of "int"
>>>>> there is not an "omission of an explicit type".
>>>>>
>>>> Cppcheck was choosed as a tool for MISRA checking and it is considering it
>>>> as a violation.
>>>
>>> Which by no means indicates that the tool pointing out something as a
>>> violation actually is one.
>>>
>>>> It treats unsigned as an implicit type. You can see this flag in cppcheck
>>>> source code:
>>>>
>>>> "fIsImplicitInt = (1U << 31), // Is "int" token implicitly added?"
>>>
>>> Neither the name of the variable nor the comment clarify that this is about
>>> the specific case of "unsigned". As said there's also the fact that they
>>> don't appear to point out the lack of "int" when seeing plain "long" (or
>>> "long long"). I fully agree that "extern x;" or "const y;" lack explicit
>>> "int".
>>
>> I am a bit puzzled here trying to understand what you actually want here.
>>
>> Do you suggest the change is ok but you are not ok with the fact that is
>> flagged
>> as MISRA fix even though cppcheck is saying otherwise ?
>
> First of all I'd like to understand whether what we're talking about here
> are actually violations (and if so, why that is). Further actions / requests
> depend on the answer.
I would say yes but this would need to be confirmed by Roberto I guess.
In any case if we think this is something we want and the change is right
and cppcheck is saying that it solves a violation, I am wondering what is
the point of discussing that extensively this change.
Cheers
Bertrand
|
