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

Re: [PATCH 0/9] MISRA C 2012 8.1 rule fixes


  • To: Bertrand Marquis <Bertrand.Marquis@xxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Wed, 22 Jun 2022 16:10:45 +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=3/x4+UAHeQPtNwfuoTJuZ4KGdODNKDMmXfrC0B7jizc=; b=W/40aoK+bBG52ABG2CHAWifhJi2GFWAYcglYK0/Sx6wkKmw6SNfxqiAPrEH3ASFod6yakCSyWCRc3AdAFl+eYizYWMxovDfemFf3I2gMVEbsVc4NZPOggbdbLRFoTIajedQH9DIP23PRP1VMq4bK2bAir1xYrUEt/GP4skbD+yxAJeOng4IvCkq+4z2lnss/iXa2k6wN4I9Fsp5gvd0sbYlaguaxAeokrqdfPSA+w53xDKDUerEpaujHVQT89JKitv4UL/YSYn6i2lhatV0eHBY6oWI7/v3gFK+H5IdLt+CBBnLGpX9HuDF1S5wbdMCWxORk5nUxgDaWuL1qoCMNwA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JQu0K3O4sdRP52ueM5kQ49vWMr9EQ9n2wExou8FLVlx0r+pCyvbVAQIng5B46pFPrg3bHmF3GsiUgZgeFsJaeskkr82HpEwgU8n261UH2LM8LP+CQHmx0xcK/g5rK8WwHd2DHrOmh1s10lzFZkpuHIeFI2w2/BvqSuoVBess37ivt/QOu/QllUh61XFtt+dXYzONticNBOP+3pCo/FwctKCyf/LuFuwZkRkVUDjhusBX1kOJPHIT8PSZ/ZoT/ErdlBf+8JJyh4tDtnik2EHQCZ7oN0meAnZFq98I0Tp4jhe0JdpJMvTMctTSVSEmKuAGxV7InU3LOUHuPSgYo4JfIw==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.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:10:59 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

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.

Jan



 


Rackspace

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