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

Re: [PATCH v5] docs/misra: new rules addition


  • To: Stefano Stabellini <sstabellini@xxxxxxxxxx>
  • From: Bertrand Marquis <Bertrand.Marquis@xxxxxxx>
  • Date: Fri, 16 Jun 2023 06:55:34 +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=fXgNCGCw7cgZgp/vYzeRfsXQDIRSVG4XAafGv3kJCvQ=; b=iexpvMOUK00eKIwCFPg/LajoQg3AEYcnU3p6ZiEXG9T2WsHe2dSvbMUaAntmiQnDWLwoHhlsV2JzS/gMx+NqTHSY1kRFan+Mesrj5gKLQNPYetjUuLeDzhLLLlY5MbHGNEj0BNqDk6zozkT6jv5WEki3zbU8d6QdAcG9vte747uunQBBl1PXS+XOL8l90pPLfjgZ2uNNFG/I5AkO7wuMKBmhgOvOLPazN6qsq/ZRxwmhZVz5+r5JJRsrxfRpjbQrQgr0rQy9vjKlj6X36Qt5A2XbFxN6xHiSTTrO8dNmPFE8S8zvpY7mfhD8BbeNRFoyTH1xzflG5GItRe87p2UX8w==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ey2I2kaGcyH/5Ix4n7w+/fA2yupOrBIkIjmdHDjUfQKSdKpDs+pHAkHf9gMkAVUpzo/bIZQMZUoyg9IHgQpPZ4D/ZjMo1MGPpm20dp+/7ic+4Ni/UeL5HlOy9X9tMJNaAp8R5pgEoWhv4q+Cf0EwHbkL7beoLH9Zs5iXVv8iw+Y9a+oWlj1vM6tlONLYNEPehXduOgVuEuJjXSM/LsSdXyNoHT6RKNrmXL3O0PhuMLSHCHaWIQOXoZNle9MTi0zluQ9qAOpXfQ2Z+UK4S+XBEx6oPbk7AageL2iz9byVTTVCcfVZJiwijpp5LJojGpC02BnZkUtF1xenWips4KR37Q==
  • Authentication-results-original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
  • Cc: Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, "julien@xxxxxxx" <julien@xxxxxxx>, "andrew.cooper3@xxxxxxxxxx" <andrew.cooper3@xxxxxxxxxx>, "roger.pau@xxxxxxxxxx" <roger.pau@xxxxxxxxxx>, "roberto.bagnara@xxxxxxxxxxx" <roberto.bagnara@xxxxxxxxxxx>, Stefano Stabellini <stefano.stabellini@xxxxxxx>, Michal Orzel <michal.orzel@xxxxxxx>
  • Delivery-date: Fri, 16 Jun 2023 06:55:59 +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: AQHZn88VmRmLP0MYHEWbK1HWPOziPK+M/22A
  • Thread-topic: [PATCH v5] docs/misra: new rules addition

Hi Stefano,

> On 15 Jun 2023, at 23:19, Stefano Stabellini <sstabellini@xxxxxxxxxx> wrote:
> 
> From: Stefano Stabellini <stefano.stabellini@xxxxxxx>
> 
> For Dir 1.1, a document describing all implementation-defined behaviour
> (i.e. gcc-specific behavior) will be added to docs/misra, also including
> implementation-specific (gcc-specific) appropriate types for bit-field
> relevant to Rule 6.1.
> 
> Rule 21.21 is lacking an example on gitlab but the rule is
> straightforward: we don't use stdlib at all in Xen.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@xxxxxxx>
> Reviewed-by: Michal Orzel <michal.orzel@xxxxxxx>

Reviewed-by: Bertrand Marquis <bertrand.marquis@xxxxxxx>

Cheers
Bertrand

> ---
> Changes in v5:
> - clarify suggested approach to Rule 7.2
> - add link for 21.21
> 
> Changes in v4:
> - improve wording of the note in 6.1
> 
> Changes in v3:
> - add all signed integer types to the Notes of 6.1
> - clarify 7.2 in the Notes
> - not added: marking "inapplicable" rules, to be a separate patch
> 
> Changes in v2:
> - drop 5.6
> - specify additional appropriate types for 6.1
> 
> iii
> ---
> docs/misra/rules.rst | 50 ++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 50 insertions(+)
> 
> diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst
> index d5a6ee8cb6..a88c284e7d 100644
> --- a/docs/misra/rules.rst
> +++ b/docs/misra/rules.rst
> @@ -40,6 +40,12 @@ existing codebase are work-in-progress.
>      - Summary
>      - Notes
> 
> +   * - `Dir 1.1 
> <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/D_01_01.c>`_
> +     - Required
> +     - Any implementation-defined behaviour on which the output of the
> +       program depends shall be documented and understood
> +     -
> +
>    * - `Dir 2.1 
> <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/D_02_01.c>`_
>      - Required
>      - All source files shall compile without any compilation errors
> @@ -57,6 +63,13 @@ existing codebase are work-in-progress.
>        header file being included more than once
>      -
> 
> +   * - `Dir 4.11 
> <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/D_04_11.c>`_
> +     - Required
> +     - The validity of values passed to library functions shall be checked
> +     - We do not have libraries in Xen (libfdt and others are not
> +       considered libraries from MISRA C point of view as they are
> +       imported in source form)
> +
>    * - `Dir 4.14 
> <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/D_04_14.c>`_
>      - Required
>      - The validity of values received from external sources shall be
> @@ -133,6 +146,12 @@ existing codebase are work-in-progress.
>        headers (xen/include/public/) are allowed to retain longer
>        identifiers for backward compatibility.
> 
> +   * - `Rule 6.1 
> <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_06_01.c>`_
> +     - Required
> +     - Bit-fields shall only be declared with an appropriate type
> +     - In addition to the C99 types, we also consider appropriate types
> +       enum and all explicitly signed / unsigned integer types.
> +
>    * - `Rule 6.2 
> <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_06_02.c>`_
>      - Required
>      - Single-bit named bit fields shall not be of a signed type
> @@ -143,6 +162,32 @@ existing codebase are work-in-progress.
>      - Octal constants shall not be used
>      -
> 
> +   * - `Rule 7.2 
> <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_07_02.c>`_
> +     - Required
> +     - A "u" or "U" suffix shall be applied to all integer constants
> +       that are represented in an unsigned type
> +     - The rule asks that any integer literal that is implicitly
> +       unsigned is made explicitly unsigned by using one of the
> +       indicated suffixes.  As an example, on a machine where the int
> +       type is 32-bit wide, 0x77777777 is signed whereas 0x80000000 is
> +       (implicitly) unsigned. In order to comply with the rule, the
> +       latter should be rewritten as either 0x80000000u or 0x80000000U.
> +       Consistency considerations may suggest using the same suffix even
> +       when not required by the rule. For instance, if one has:
> +
> +       Original: f(0x77777777); f(0x80000000);
> +
> +       one should do
> +
> +       Solution 1: f(0x77777777U); f(0x80000000U);
> +
> +       over
> +
> +       Solution 2: f(0x77777777); f(0x80000000U);
> +
> +       after having ascertained that "Solution 1" is compatible with the
> +       intended semantics.
> +
>    * - `Rule 7.3 
> <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_07_03.c>`_
>      - Required
>      - The lowercase character l shall not be used in a literal suffix
> @@ -314,6 +359,11 @@ existing codebase are work-in-progress.
>        used following a subsequent call to the same function
>      -
> 
> +   * - `Rule 21.21 
> <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/>`_
> +     - Required
> +     - The Standard Library function system of <stdlib.h> shall not be used
> +     -
> +
>    * - `Rule 22.2 
> <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_22_02.c>`_
>      - Mandatory
>      - A block of memory shall only be freed if it was allocated by means of a
> -- 
> 2.25.1
> 




 


Rackspace

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