[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 0/9] MISRA C 2012 8.1 rule fixes
- To: Michal Orzel <michal.orzel@xxxxxxx>
- From: Jan Beulich <jbeulich@xxxxxxxx>
- Date: Wed, 22 Jun 2022 15:01:59 +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=RBj2JPc8UpYI6OEVt6nbuwqcrZmOnCzFbEe9Osq+8Hw=; b=Hrmbf12meiE3cEm3Qm+hcrmj281qVyHuz1wSq6cRymJUaRGSwPQFoQ1VaCOzfib+wuyXk5n0KIRM9TF74xOBp6hurjKKixWyVJzV4xvhgbot5uZFr0IR5f7BxkBU2S3+Kxh1HUgf5MtroeWxpQpbgT/0T9otYmWXyQ+xL06808NwUdSNO2nKVyI2UFDLuJyMRYMtpnBwwIATpR15v+qRRIISY9vcvFGInUSXYNzOnYKsFwVpAxVeSO/xRJOCG/LGSOnR1IhSOkIBbc6LkYWafk2U28sLxWfVLzVNC4s778Ids64hBhwp2qwXAgRH0bxy2vVqrLSKCX0uybFvnyo9ww==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ME9P2woINjOebr93xuRszgsiubPmbObpWkafEk9ofJLqPSlFFPbWrwxqCoClz1cLp4RAcsNCXMWCaMMMYc5bkZW/nAwVLaWS+cphiScQRIaLYpK9iNhMQr+EG5U31H8lwsMSRqEOOcMx5ENiolq0yk0gJeBsr8pRaJBbbqMgu/Ed6OEC/zSh+15JLTRcjBf7/wJ7/nla5hQQ3xWVjNhXWMyDdeJZqWEjZ3rhWw8g2t/iyiiETBxuiOF8Bkzh38vu5RGq+JF/MMoNSDOM+YPebYALFgNXi7Csf8YKspYkWtjQyIvrdC198jir6JBv1slTDiitGTPM0DJV6aPEAzOS3w==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
- Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Bertrand Marquis <bertrand.marquis@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
- Delivery-date: Wed, 22 Jun 2022 13:02:11 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
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".
Jan
|
