[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [XEN PATCH] xen: Add SAF deviations for MISRA C:2012 Rule 7.1
- To: Stefano Stabellini <sstabellini@xxxxxxxxxx>
- From: Luca Fancellu <Luca.Fancellu@xxxxxxx>
- Date: Mon, 9 Oct 2023 08:09:49 +0000
- Accept-language: en-GB, en-US
- 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=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=IeHYZgPOkRfRU58T+8bb0aPnAZtVyoIphMkF+3yvsjk=; b=NmnZYs1nhrCJUuQMl355A2mXfDPsYmKlFOJUwJEJPLVsUNIqWRVjE9BnR0XiHt6qMkedsvAMoe0Dnrqrrd15TegnO7xp8y40J5VoFL0NwabpzpKmQzQZHnNpLnJ/PFPTzl1Cph8jhXldnl9rMrs5SR/YM/B7wPyrlJAqF/klhLGUgBo1Hu1P7Yo6aaKAp/uBVadx9DWbQzGK7JOou90u8f0i6tBpwuoDFsKg4st6aI6AT1X3EIxh/QlFgSs4ilphKYW17aqO/4bxX6xEeLKe4Qtjy3FYH5kXfpxVysH5WB9Cxw/a6ooe+l3KjEXHm0bVA9YBBMT+8wS4DpYRXoyI6Q==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UFv6P1+fIEsygZ1yST71GGSI6cM9bUvdKbxHvU2w6TQ/5fe+VcYE0dx0IJ3XDGy4ttGmgnauE82rNAsphLYuIAk52RlGWVQ+mFxl8kEPB4TQCQJo28COWfwBjwkxmUAQ5XOKAAZE7tbusO85v+U+VZN71J6d6l0Ah36DtadOHuqIRJKoY4HPpGYm7ebXSpDrXD6diE/h/6Cx6QiEXRM2eif/nDlDoEFg3/MGrxhMUHn7z337U2l+NCNPKk446YKb3q82Us6laR30ARVAiLoBvt+55bWttTdY5B19qM6+7u0ChT7OJlDwslxkanH/h8T216fNfZmInkq9qLO6LvttKg==
- Authentication-results-original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
- Cc: Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, "michal.orzel@xxxxxxx" <michal.orzel@xxxxxxx>, "xenia.ragiadakou@xxxxxxx" <xenia.ragiadakou@xxxxxxx>, Ayan Kumar Halder <ayan.kumar.halder@xxxxxxx>, "consulting@xxxxxxxxxxx" <consulting@xxxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Henry Wang <Henry.Wang@xxxxxxx>, Simone Ballarin <simone.ballarin@xxxxxxxxxxx>, Doug Goldstein <cardoe@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Wei Liu <wl@xxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
- Delivery-date: Mon, 09 Oct 2023 08:10:53 +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: AQHZ9qj87vFsnMRst0ybMa+ffKOLU7A5Z4mAgAAGhgCAAAYzgIAA1KIAgACGqQCAASTEgIAAdASAgAEY6ICAA6FXgA==
- Thread-topic: [XEN PATCH] xen: Add SAF deviations for MISRA C:2012 Rule 7.1
>>>
>>> Right so the results would be all off by a few lines of code so when
>>> you go to read the report generated by cppcheck, the references
>>> wouldn't match anymore.
>>>
>>> Before giving up and accepting that we are constrained to only formats
>>> that don't change the LOC numbers, can we check what Coverity supports?
>>>
>>> I am asking because we could get away with implementing the formats
>>> above in cppcheck, given that cppcheck is open source. But for Coverity
>>> we need to stay with what is already supported by it.
>>>
>>> Does Coverity support anything other than:
>>>
>>> <tag on previous line>
>>> <next line is code with deviation>
>>
>> Unfortunately not, from its documentation I can’t see anything apart from
>> the above,
>> I can ask someone from synopsys though to double check.
>
> I wonder how people would feel to have an exception to our coding style
> in these cases and have longer than 80 chars lines. I am asking because
> this is better than many of the other options above:
>
> /* SAF-x-safe */
> if ( modrm_mod == MASK_EXTR(instr_modrm, 0300) && (modrm_reg & 7) ==
> MASK_EXTR(instr_modrm, 0070) && (modrm_rm & 7) == MASK_EXTR(instr_modrm,
> 0007) )
>
> Any other ideas?
Hi Stefano,
I’ve suggested some mails ago to use #define for the MASK_EXTR so that
every instance of the violation goes into a different line, but this works only
If Eclair is throwing the violation at the definition and not at its usage.
I remember we had a discussion months ago about that but I don’t remember
If Roberto told us that this behaviour can be adjusted in Eclair or not.
An exception in the coding style would make the adoption of an automatic tool
difficult.
Cheers,
Luca
|
