[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




 


Rackspace

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