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

Re: [XEN PATCH][for-4.19 v3] xen: Add deviations for MISRA C:2012 Rule 7.1


  • To: Stefano Stabellini <sstabellini@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Thu, 26 Oct 2023 08:49:16 +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=ScXXPbgvfg69sK5/V/jSimFsnBtWPz1Bf5ddu0j4Bz0=; b=QAhDlZbGjkNHRf0VDI586HfJGNTDADcJWzNGoH0NeNCkZmml2u/CV4NX0N89zeATrZ3PVDtH8Qc3IducJgfsb66DD/Nih7qbGLqrvx5k6cBbUu4sU0iC0YZBgA/hV0TwFXo4y8QS+30CvCS8aqJBYJMxpybjg8q6d2a7yWu9lQbFlGj8VjCK9ZCnLWCK0L7MPMH2Nj5YdPy6k0yqoyAtSOb+c9hoKqh9Wyt02ejk4v6hYbkxKwrPla5MLEpu6zE8nP1LR/40yfC0lUT8xOqxOjhy09IyXXz0oW6/lE/h7LGZF3ZvQnlrVza1IUcFQsqfe5YIcER8XlUpvKk3azMCyQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oRjjwUM8Qea+jwG0KqfqCNmw0wrkXrHGGScLmaUMbKZlV+NM8GHvxKsnA3XJJuXkLcT0y2ysfoJyynUUarNch2kaE+z0jNJbVFqZwD/KmCnBqS4+IKBSlfDuEFdP1he5YJ6/TjhSLvaOKfXLdTZmMj8aPo41mjk88rhCftIxaBLDJ9rhtzcwdQwCi+21ePd+qR09K22KA7JdAu24WSFEUncj9CRhXZuziDBwecyu0YMkNEapjvimEAisd+lGneiYgwEqcfdk2xIrQoI7y3QuDM9LoBz2TFFSJvmLqtSx7P9+9hpgiAzi/byceDyyw6jU+0xtDdettDjCNk2JrDzJGQ==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx, michal.orzel@xxxxxxx, xenia.ragiadakou@xxxxxxx, ayan.kumar.halder@xxxxxxx, consulting@xxxxxxxxxxx, andrew.cooper3@xxxxxxxxxx, roger.pau@xxxxxxxxxx, Simone Ballarin <simone.ballarin@xxxxxxxxxxx>, Doug Goldstein <cardoe@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Wei Liu <wl@xxxxxxx>, Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>
  • Delivery-date: Thu, 26 Oct 2023 06:49:27 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 26.10.2023 00:34, Stefano Stabellini wrote:
> On Wed, 25 Oct 2023, Jan Beulich wrote:
>> On 24.10.2023 22:30, Stefano Stabellini wrote:
>>> On Tue, 24 Oct 2023, Nicola Vetrini wrote:
>>>> As specified in rules.rst, these constants can be used
>>>> in the code.
>>>>
>>>> Signed-off-by: Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>
>>>> ---
>>>> Changes in v2:
>>>> - replace some SAF deviations with configurations
>>>> Changes in v3:
>>>> - refine configurations and justifications
>>>> ---
>>>>  automation/eclair_analysis/ECLAIR/deviations.ecl | 10 ++++++----
>>>>  docs/misra/deviations.rst                        |  5 +++++
>>>>  docs/misra/safe.json                             |  8 ++++++++
>>>>  xen/arch/x86/hvm/svm/emulate.c                   |  6 +++---
>>>>  xen/common/inflate.c                             |  4 ++--
>>>>  5 files changed, 24 insertions(+), 9 deletions(-)
>>>>
>>>> diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl 
>>>> b/automation/eclair_analysis/ECLAIR/deviations.ecl
>>>> index fa56e5c00a27..ea5e0eb1813f 100644
>>>> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
>>>> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
>>>> @@ -85,10 +85,12 @@ conform to the directive."
>>>>  # Series 7.
>>>>  #
>>>>  
>>>> --doc_begin="Usage of the following constants is safe, since they are 
>>>> given as-is
>>>> -in the inflate algorithm specification and there is therefore no risk of 
>>>> them
>>>> -being interpreted as decimal constants."
>>>> --config=MC3R1.R7.1,literals={safe, 
>>>> "^0(007|37|070|213|236|300|321|330|331|332|333|334|335|337|371)$"}
>>>> +-doc_begin="It is safe to use certain octal constants the way they are 
>>>> defined in
>>>> +specifications, manuals, and algorithm descriptions."
>>>> +-file_tag+={x86_svm_h, "^xen/arch/x86/hvm/svm/svm\\.h$"}
>>>> +-file_tag+={x86_emulate_c, "^xen/arch/x86/hvm/svm/emulate\\.c$"}
>>>> +-config=MC3R1.R7.1,reports+={safe, 
>>>> "any_area(any_loc(any_exp(file(x86_svm_h)&&macro(^INSTR_ENC$))))"}
>>>> +-config=MC3R1.R7.1,reports+={safe, 
>>>> "any_area(text(^.*octal-ok.*$)&&any_loc(any_exp(file(x86_emulate_c)&&macro(^MASK_EXTR$))))"}
>>>>  -doc_end
>>>>  
>>>>  -doc_begin="Violations in files that maintainers have asked to not modify 
>>>> in the
>>>> diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst
>>>> index 8511a189253b..26c6dbbc9ffe 100644
>>>> --- a/docs/misra/deviations.rst
>>>> +++ b/docs/misra/deviations.rst
>>>> @@ -90,6 +90,11 @@ Deviations related to MISRA C:2012 Rules:
>>>>           - __emulate_2op and __emulate_2op_nobyte
>>>>           - read_debugreg and write_debugreg
>>>>  
>>>> +   * - R7.1
>>>> +     - It is safe to use certain octal constants the way they are defined 
>>>> in
>>>> +       specifications, manuals, and algorithm descriptions.
>>>
>>> I think we should add that these cases have "octal-ok" as a in-code
>>> comment. Everything else looks OK so this small change could be done on
>>> commit.
>>
>> But that needs wording carefully, as it doesn't hold across the board:
>> Right now relevant MASK_EXTR() uses gain such comments, but INSTR_ENC()
>> ones (deliberately) don't.
> 
> What about:
> 
> * - R7.1
>   - It is safe to use certain octal constants the way they are defined
>     in specifications, manuals, and algorithm descriptions. Such places
>     are marked safe with a /* octal-ok */ in-code comment, or with a SAF
>     comment (see safe.json).

Fine with me.

Jan



 


Rackspace

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