Coding Guidelines 한국어 번역

Part 1

요약·해설

Stage I~IV 적용 전략, MISRA-C:2012 부분집합 147개, CERT C와 공식 예제, 조건부 컴파일·포용적 언어·매크로 충돌·kernel과 전체 codebase의 libc 제한을 다룹니다.

Scope

147 MISRA Rules

Safety

Mandatory · Required

Zephyr

Additional A.1-A.5

Part 2

접을 수 있는 영어 원문 전체

영어 원문 전체 펼치기

원문 SHA-256 7BF82ACA31463C76B9337D9DEA84F7752E0E6C7CCBEBDB487E37B4CA1462CB7B

.. _coding_guidelines:

Coding Guidelines
#################

The project TSC and the Safety Committee of the project agreed to implement
a staged and incremental approach for complying with a set of coding rules (AKA
Coding Guidelines) to improve quality and consistency of the code base. Below
are the agreed upon stages:

Stage I (COMPLETED)
  Coding guideline rules are available to be followed and referenced,
  but not enforced. Rules are not yet enforced in CI and pull-requests cannot be
  blocked by reviewers/approvers due to violations.

Stage II
  Begin enforcement on a limited scope of the code base. Initially, this would be
  the safety certification scope. For rules easily applied across codebase, we
  should not limit compliance to initial scope. This step requires tooling,
  CI setup and an enforcement strategy.

Stage III
  Revisit the coding guideline rules and based on experience from previous
  stages, refine/iterate on selected rules.

Stage IV
   Expand enforcement to the wider codebase. Exceptions may be granted on some
   areas of the codebase with a proper justification. Exception would require
   TSC approval.

.. note::

    Coding guideline rules may be removed/changed at any time by filing a
    GH issue/RFC.

.. important::

    **Current stage:**
    The prerequisites for entering **Stage II** are currently being looked at:
    The tooling is in evaluation, CI setup and `enforcement strategy
    <https://github.com/zephyrproject-rtos/zephyr/issues/58903>`__ is being worked on.

Main rules
**********

The coding guideline rules are based on MISRA-C 2012 and are a subset of MISRA-C.
The subset is listed in the table below with a summary of the rules, its
severity and the equivalent rules from other standards for reference.

.. note::

    For existing Zephyr maintainers and collaborators, if you are unable to
    obtain a copy through your employer, a limited number of copies will be made
    available through the project. If you need a copy of MISRA-C 2012, please
    send email to [email protected] and provide details on reason
    why you can't obtain one through other options and expected contributions
    once you have one.  The safety committee will review all requests.


.. list-table:: Main rules
    :header-rows: 1
    :widths: 17 14 43 12 14

    * -  MISRA C 2012
      -  Severity
      -  Description
      -  CERT C
      -  Example

         .. _MisraC_Dir_1_1:
    * -  Dir 1.1
      -  Required
      -  Any implementation-defined behaviour on which the output of the program depends shall be documented and understood
      -  `MSC09-C <https://wiki.sei.cmu.edu/confluence/display/c/MSC09-C.+Character+encoding%3A+Use+subset+of+ASCII+for+safety>`_
      -  `Dir 1.1 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/D_01_01.c>`_

         .. _MisraC_Dir_2_1:
    * -  Dir 2.1
      -  Required
      -  All source files shall compile without any compilation errors
      -  N/A
      -  `Dir 2.1 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/D_02_01.c>`_

         .. _MisraC_Dir_3_1:
    * -  Dir 3.1
      -  Required
      -  All code shall be traceable to documented requirements
      -  N/A
      -  `Dir 3.1 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/D_03_01.c>`_

         .. _MisraC_Dir_4_1:
    * -  Dir 4.1
      -  Required
      -  Run-time failures shall be minimized
      -  N/A
      -  `Dir 4.1 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/D_04_01.c>`_

         .. _MisraC_Dir_4_2:
    * -  Dir 4.2
      -  Advisory
      -  All usage of assembly language should be documented
      -  N/A
      -  `Dir 4.2 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/D_04_02.c>`_

         .. _MisraC_Dir_4_4:
    * -  Dir 4.4
      -  Advisory
      -  Sections of code should not be “commented out”
      -  `MSC04-C <https://wiki.sei.cmu.edu/confluence/display/c/MSC04-C.+Use+comments+consistently+and+in+a+readable+fashion>`_
      -  `Dir 4.4 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/D_04_04.c>`_

         .. _MisraC_Dir_4_5:
    * -  Dir 4.5
      -  Advisory
      -  Identifiers in the same name space with overlapping visibility should be typographically unambiguous
      -  `DCL02-C <https://wiki.sei.cmu.edu/confluence/display/c/DCL02-C.+Use+visually+distinct+identifiers>`_
      -  `Dir 4.5 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/D_04_05.c>`_

         .. _MisraC_Dir_4_6:
    * -  Dir 4.6
      -  Advisory
      -  typedefs that indicate size and signedness should be used in place of the basic numerical types
      -  N/A
      -  `Dir 4.6 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/D_04_06.c>`_

         .. _MisraC_Dir_4_7:
    * -  Dir 4.7
      -  Required
      -  If a function returns error information, then that error information shall be tested
      -  N/A
      -  `Dir 4.7 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/D_04_07.c>`_

         .. _MisraC_Dir_4_8:
    * -  Dir 4.8
      -  Advisory
      -  If a pointer to a structure or union is never dereferenced within a translation unit, then the implementation of the object should be hidden
      -  `DCL12-C <https://wiki.sei.cmu.edu/confluence/display/c/DCL12-C.+Implement+abstract+data+types+using+opaque+types>`_
      -  | `Dir 4.8 example 1 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/D_04_08_1.c>`_
         | `Dir 4.8 example 2 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/D_04_08_2.c>`_

         .. _MisraC_Dir_4_9:
    * -  Dir 4.9
      -  Advisory
      -  A function should be used in preference to a function-like macro where they are interchangeable
      -  `PRE00-C <https://wiki.sei.cmu.edu/confluence/display/c/PRE00-C.+Prefer+inline+or+static+functions+to+function-like+macros>`_
      -  `Dir 4.9 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/D_04_09.c>`_

         .. _MisraC_Dir_4_10:
    * -  Dir 4.10
      -  Required
      -  Precautions shall be taken in order to prevent the contents of a header file being included more than once
      -  `PRE06-C <https://wiki.sei.cmu.edu/confluence/display/c/PRE06-C.+Enclose+header+files+in+an+include+guard>`_
      -  `Dir 4.10 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/D_04_10.c>`_

         .. _MisraC_Dir_4_11:
    * -  Dir 4.11
      -  Required
      -  The validity of values passed to library functions shall be checked
      -  N/A
      -  `Dir 4.11 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/D_04_11.c>`_

         .. _MisraC_Dir_4_12:
    * -  Dir 4.12
      -  Required
      -  Dynamic memory allocation shall not be used
      -  `STR01-C <https://wiki.sei.cmu.edu/confluence/display/c/STR01-C.+Adopt+and+implement+a+consistent+plan+for+managing+strings>`_
      -  `Dir 4.12 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/D_04_12.c>`_

         .. _MisraC_Dir_4_13:
    * -  Dir 4.13
      -  Advisory
      -  Functions which are designed to provide operations on a resource should be called in an appropriate sequence
      -  N/A
      -  `Dir 4.13 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/D_04_13.c>`_

         .. _MisraC_Dir_4_14:
    * -  Dir 4.14
      -  Required
      -  The validity of values received from external sources shall be checked

      -  N/A
      -  `Dir 4.14 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/D_04_14.c>`_

         .. _MisraC_Rule_1_2:
    * -  Rule 1.2
      -  Advisory
      -  Language extensions should not be used
      -  `MSC04-C <https://wiki.sei.cmu.edu/confluence/display/c/MSC04-C.+Use+comments+consistently+and+in+a+readable+fashion>`_
      -  `Rule 1.2 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_01_02.c>`_

         .. _MisraC_Rule_1_3:
    * -  Rule 1.3
      -  Required
      -  There shall be no occurrence of undefined or critical unspecified behaviour
      -  N/A
      -  `Rule 1.3 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_01_03.c>`_

         .. _MisraC_Rule_2_1:
    * -  Rule 2.1
      -  Required
      -  A project shall not contain unreachable code
      -  `MSC07-C <https://wiki.sei.cmu.edu/confluence/display/c/MSC07-C.+Detect+and+remove+dead+code>`_
      -  | `Rule 2.1 example 1 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_02_01_1.c>`_
         | `Rule 2.1 example 2 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_02_01_2.c>`_

         .. _MisraC_Rule_2_2:
    * -  Rule 2.2
      -  Required
      -  There shall be no dead code
      -  `MSC12-C <https://wiki.sei.cmu.edu/confluence/display/c/MSC12-C.+Detect+and+remove+code+that+has+no+effect+or+is+never+executed>`_
      -  `Rule 2.2 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_02_02.c>`_

         .. _MisraC_Rule_2_3:
    * -  Rule 2.3
      -  Advisory
      -  A project should not contain unused type declarations
      -  N/A
      -  `Rule 2.3 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_02_03.c>`_

         .. _MisraC_Rule_2_6:
    * -  Rule 2.6
      -  Advisory
      -  A function should not contain unused label declarations
      -  N/A
      -  `Rule 2.6 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_02_06.c>`_

         .. _MisraC_Rule_2_7:
    * -  Rule 2.7
      -  Advisory
      -  There should be no unused parameters in functions
      -  N/A
      -  `Rule 2.7 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_02_07.c>`_

         .. _MisraC_Rule_3_1:
    * -  Rule 3.1
      -  Required
      -  The character sequences /* and // shall not be used within a comment
      -  `MSC04-C <https://wiki.sei.cmu.edu/confluence/display/c/MSC04-C.+Use+comments+consistently+and+in+a+readable+fashion>`_
      -  `Rule 3.1 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_03_01.c>`_

         .. _MisraC_Rule_3_2:
    * -  Rule 3.2
      -  Required
      -  Line-splicing shall not be used in // comments
      -  N/A
      -  `Rule 3.2 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_03_02.c>`_

         .. _MisraC_Rule_4_1:
    * -  Rule 4.1
      -  Required
      -  Octal and hexadecimal escape sequences shall be terminated
      -  `MSC09-C <https://wiki.sei.cmu.edu/confluence/display/c/MSC09-C.+Character+encoding%3A+Use+subset+of+ASCII+for+safety>`_
      -  `Rule 4.1 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_04_01.c>`_

         .. _MisraC_Rule_4_2:
    * -  Rule 4.2
      -  Advisory
      -  Trigraphs should not be used
      -  `PRE07-C <https://wiki.sei.cmu.edu/confluence/display/c/PRE07-C.+Avoid+using+repeated+question+marks>`_
      -  `Rule 4.2 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_04_02.c>`_

         .. _MisraC_Rule_5_1:
    * -  Rule 5.1
      -  Required
      -  External identifiers shall be distinct
      -  `DCL23-C <https://wiki.sei.cmu.edu/confluence/display/c/DCL23-C.+Guarantee+that+mutually+visible+identifiers+are+unique>`_
      -  | `Rule 5.1 example 1 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_05_01_1.c>`_
         | `Rule 5.1 example 2 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_05_01_2.c>`_

         .. _MisraC_Rule_5_2:
    * -  Rule 5.2
      -  Required
      -  Identifiers declared in the same scope and name space shall be distinct
      -  `DCL23-C <https://wiki.sei.cmu.edu/confluence/display/c/DCL23-C.+Guarantee+that+mutually+visible+identifiers+are+unique>`_
      -  `Rule 5.2 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_05_02.c>`_

         .. _MisraC_Rule_5_3:
    * -  Rule 5.3
      -  Required
      -  An identifier declared in an inner scope shall not hide an identifier declared in an outer scope
      -  `DCL23-C <https://wiki.sei.cmu.edu/confluence/display/c/DCL23-C.+Guarantee+that+mutually+visible+identifiers+are+unique>`_
      -  `Rule 5.3 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_05_03.c>`_

         .. _MisraC_Rule_5_4:
    * -  Rule 5.4
      -  Required
      -  Macro identifiers shall be distinct
      -  `DCL23-C <https://wiki.sei.cmu.edu/confluence/display/c/DCL23-C.+Guarantee+that+mutually+visible+identifiers+are+unique>`_
      -  `Rule 5.4 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_05_04.c>`_

         .. _MisraC_Rule_5_5:
    * -  Rule 5.5
      -  Required
      -  Identifiers shall be distinct from macro names
      -  `DCL23-C <https://wiki.sei.cmu.edu/confluence/display/c/DCL23-C.+Guarantee+that+mutually+visible+identifiers+are+unique>`_
      -  `Rule 5.5 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_05_05.c>`_

         .. _MisraC_Rule_5_6:
    * -  Rule 5.6
      -  Required
      -  A typedef name shall be a unique identifier
      -  N/A
      -  `Rule 5.6 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_05_06.c>`_

         .. _MisraC_Rule_5_7:
    * -  Rule 5.7
      -  Required
      -  A tag name shall be a unique identifier
      -  N/A
      -  `Rule 5.7 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_05_07.c>`_

         .. _MisraC_Rule_5_8:
    * -  Rule 5.8
      -  Required
      -  Identifiers that define objects or functions with external linkage shall be unique
      -  N/A
      -  | `Rule 5.8 example 1 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_05_08_1.c>`_
         | `Rule 5.8 example 2 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_05_08_2.c>`_

         .. _MisraC_Rule_5_9:
    * -  Rule 5.9
      -  Advisory
      -  Identifiers that define objects or functions with internal linkage should be unique
      -  N/A
      -  | `Rule 5.9 example 1 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_05_09_1.c>`_
         | `Rule 5.9 example 2 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_05_09_2.c>`_

         .. _MisraC_Rule_6_1:
    * -  Rule 6.1
      -  Required
      -  Bit-fields shall only be declared with an appropriate type
      -  `INT14-C <https://wiki.sei.cmu.edu/confluence/display/c/INT14-C.+Avoid+performing+bitwise+and+arithmetic+operations+on+the+same+data>`_
      -  `Rule 6.1 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_06_01.c>`_

         .. _MisraC_Rule_6_2:
    * -  Rule 6.2
      -  Required
      -  Single-bit named bit fields shall not be of a signed type
      -  `INT14-C <https://wiki.sei.cmu.edu/confluence/display/c/INT14-C.+Avoid+performing+bitwise+and+arithmetic+operations+on+the+same+data>`_
      -  `Rule 6.2 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_06_02.c>`_

         .. _MisraC_Rule_7_1:
    * -  Rule 7.1
      -  Required
      -  Octal constants shall not be used
      -  `DCL18-C <https://wiki.sei.cmu.edu/confluence/display/c/DCL18-C.+Do+not+begin+integer+constants+with+0+when+specifying+a+decimal+value>`_
      -  `Rule 7.1 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_07_01.c>`_

         .. _MisraC_Rule_7_2:
    * -  Rule 7.2
      -  Required
      -  A u or U suffix shall be applied to all integer constants that are represented in an unsigned type
      -  N/A
      -  `Rule 7.2 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_07_02.c>`_

         .. _MisraC_Rule_7_3:
    * -  Rule 7.3
      -  Required
      -  The lowercase character l shall not be used in a literal suffix
      -  `DCL16-C <https://wiki.sei.cmu.edu/confluence/pages/viewpage.action?pageId=87152241>`_
      -  `Rule 7.3 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_07_03.c>`_

         .. _MisraC_Rule_7_4:
    * -  Rule 7.4
      -  Required
      -  A string literal shall not be assigned to an object unless the objects type is pointer to const-qualified char
      -  N/A
      -  `Rule 7.4 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_07_04.c>`_

         .. _MisraC_Rule_8_1:
    * -  Rule 8.1
      -  Required
      -  Types shall be explicitly specified
      -  N/A
      -  `Rule 8.1 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_08_01.c>`_

         .. _MisraC_Rule_8_2:
    * -  Rule 8.2
      -  Required
      -  Function types shall be in prototype form with named parameters
      -  `DCL20-C <https://wiki.sei.cmu.edu/confluence/display/c/DCL20-C.+Explicitly+specify+void+when+a+function+accepts+no+arguments>`_
      -  `Rule 8.2 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_08_02.c>`_

         .. _MisraC_Rule_8_3:
    * -  Rule 8.3
      -  Required
      -  All declarations of an object or function shall use the same names and type qualifiers
      -  N/A
      -  `Rule 8.3 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_08_03.c>`_

         .. _MisraC_Rule_8_4:
    * -  Rule 8.4
      -  Required
      -  A compatible declaration shall be visible when an object or function with external linkage is defined
      -  N/A
      -  `Rule 8.4 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_08_04.c>`_

         .. _MisraC_Rule_8_5:
    * -  Rule 8.5
      -  Required
      -  An external object or function shall be declared once in one and only one file
      -  N/A
      -  | `Rule 8.5 example 1 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_08_05_1.c>`_
         | `Rule 8.5 example 2 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_08_05_2.c>`_

         .. _MisraC_Rule_8_6:
    * -  Rule 8.6
      -  Required
      -  An identifier with external linkage shall have exactly one external definition
      -  N/A
      -  | `Rule 8.6 example 1 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_08_06_1.c>`_
         | `Rule 8.6 example 2 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_08_06_2.c>`_

         .. _MisraC_Rule_8_8:
    * -  Rule 8.8
      -  Required
      -  The static storage class specifier shall be used in all declarations of objects and functions that have internal linkage
      -  `DCL15-C <https://wiki.sei.cmu.edu/confluence/display/c/DCL15-C.+Declare+file-scope+objects+or+functions+that+do+not+need+external+linkage+as+static>`_
      -  `Rule 8.8 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_08_08.c>`_

         .. _MisraC_Rule_8_9:
    * -  Rule 8.9
      -  Advisory
      -  An object should be defined at block scope if its identifier only appears in a single function
      -  `DCL19-C <https://wiki.sei.cmu.edu/confluence/display/c/DCL19-C.+Minimize+the+scope+of+variables+and+functions>`_
      -  `Rule 8.9 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_08_09.c>`_

         .. _MisraC_Rule_8_10:
    * -  Rule 8.10
      -  Required
      -  An inline function shall be declared with the static storage class
      -  N/A
      -  `Rule 8.10 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_08_10.c>`_

         .. _MisraC_Rule_8_12:
    * -  Rule 8.12
      -  Required
      -  Within an enumerator list, the value of an implicitly-specified enumeration constant shall be unique
      -  `INT09-C <https://wiki.sei.cmu.edu/confluence/display/c/INT09-C.+Ensure+enumeration+constants+map+to+unique+values>`_
      -  `Rule 8.12 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_08_12.c>`_

         .. _MisraC_Rule_8_14:
    * -  Rule 8.14
      -  Required
      -  The restrict type qualifier shall not be used
      -  N/A
      -  `Rule 8.14 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_08_14.c>`_

         .. _MisraC_Rule_9_1:
    * -  Rule 9.1
      -  Mandatory
      -  The value of an object with automatic storage duration shall not be read before it has been set
      -  N/A
      -  `Rule 9.1 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_09_01.c>`_

         .. _MisraC_Rule_9_2:
    * -  Rule 9.2
      -  Required
      -  The initializer for an aggregate or union shall be enclosed in braces
      -  N/A
      -  `Rule 9.2 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_09_02.c>`_

         .. _MisraC_Rule_9_3:
    * -  Rule 9.3
      -  Required
      -  Arrays shall not be partially initialized
      -  N/A
      -  `Rule 9.3 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_09_03.c>`_

         .. _MisraC_Rule_9_4:
    * -  Rule 9.4
      -  Required
      -  An element of an object shall not be initialized more than once
      -  N/A
      -  `Rule 9.4 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_09_04.c>`_

         .. _MisraC_Rule_9_5:
    * -  Rule 9.5
      -  Required
      -  Where designated initializers are used to initialize an array object the size of the array shall be specified explicitly
      -  N/A
      -  `Rule 9.5 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_09_05.c>`_

         .. _MisraC_Rule_10_1:
    * -  Rule 10.1
      -  Required
      -  Operands shall not be of an inappropriate essential type
      -  `STR04-C <https://wiki.sei.cmu.edu/confluence/display/c/STR04-C.+Use+plain+char+for+characters+in+the+basic+character+set>`_
      -  `Rule 10.1 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_10_01.c>`_

         .. _MisraC_Rule_10_2:
    * -  Rule 10.2
      -  Required
      -  Expressions of essentially character type shall not be used inappropriately in addition and subtraction operations
      -  `STR04-C <https://wiki.sei.cmu.edu/confluence/display/c/STR04-C.+Use+plain+char+for+characters+in+the+basic+character+set>`_
      -  `Rule 10.2 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_10_02.c>`_

         .. _MisraC_Rule_10_3:
    * -  Rule 10.3
      -  Required
      -  The value of an expression shall not be assigned to an object with a narrower essential type or of a different essential type category
      -  `STR04-C <https://wiki.sei.cmu.edu/confluence/display/c/STR04-C.+Use+plain+char+for+characters+in+the+basic+character+set>`_
      -  `Rule 10.3 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_10_03.c>`_

         .. _MisraC_Rule_10_4:
    * -  Rule 10.4
      -  Required
      -  Both operands of an operator in which the usual arithmetic conversions are performed shall have the same essential type category
      -  `STR04-C <https://wiki.sei.cmu.edu/confluence/display/c/STR04-C.+Use+plain+char+for+characters+in+the+basic+character+set>`_
      -  `Rule 10.4 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_10_04.c>`_

         .. _MisraC_Rule_10_5:
    * -  Rule 10.5
      -  Advisory
      -  The value of an expression should not be cast to an inappropriate essential type
      -  N/A
      -  `Rule 10.5 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_10_05.c>`_

         .. _MisraC_Rule_10_6:
    * -  Rule 10.6
      -  Required
      -  The value of a composite expression shall not be assigned to an object with wider essential type
      -  `INT02-C <https://wiki.sei.cmu.edu/confluence/display/c/INT02-C.+Understand+integer+conversion+rules>`_
      -  `Rule 10.6 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_10_06.c>`_

         .. _MisraC_Rule_10_7:
    * -  Rule 10.7
      -  Required
      -  If a composite expression is used as one operand of an operator in which the usual arithmetic conversions are performed then the other operand shall not have wider essential type
      -  `INT02-C <https://wiki.sei.cmu.edu/confluence/display/c/INT02-C.+Understand+integer+conversion+rules>`_
      -  `Rule 10.7 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_10_07.c>`_

         .. _MisraC_Rule_10_8:
    * -  Rule 10.8
      -  Required
      -  The value of a composite expression shall not be cast to a different essential type category or a wider essential type
      -  `INT02-C <https://wiki.sei.cmu.edu/confluence/display/c/INT02-C.+Understand+integer+conversion+rules>`_
      -  `Rule 10.8 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_10_08.c>`_

         .. _MisraC_Rule_11_2:
    * -  Rule 11.2
      -  Required
      -  Conversions shall not be performed between a pointer to an incomplete type and any other type
      -  N/A
      -  `Rule 11.2 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_11_02.c>`_

         .. _MisraC_Rule_11_6:
    * -  Rule 11.6
      -  Required
      -  A cast shall not be performed between pointer to void and an arithmetic type
      -  N/A
      -  `Rule 11.6 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_11_06.c>`_

         .. _MisraC_Rule_11_7:
    * -  Rule 11.7
      -  Required
      -  A cast shall not be performed between pointer to object and a noninteger arithmetic type
      -  N/A
      -  `Rule 11.7 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_11_07.c>`_

         .. _MisraC_Rule_11_8:
    * -  Rule 11.8
      -  Required
      -  A cast shall not remove any const or volatile qualification from the type pointed to by a pointer
      -  `EXP05-C <https://wiki.sei.cmu.edu/confluence/display/c/EXP05-C.+Do+not+cast+away+a+const+qualification>`_
      -  `Rule 11.8 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_11_08.c>`_

         .. _MisraC_Rule_11_9:
    * -  Rule 11.9
      -  Required
      -  The macro NULL shall be the only permitted form of integer null pointer constant
      -  N/A
      -  `Rule 11.9 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_11_09.c>`_

         .. _MisraC_Rule_12_1:
    * -  Rule 12.1
      -  Advisory
      -  The precedence of operators within expressions should be made explicit
      -  `EXP00-C <https://wiki.sei.cmu.edu/confluence/display/c/EXP00-C.+Use+parentheses+for+precedence+of+operation>`_
      -  `Rule 12.1 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_12_01.c>`_

         .. _MisraC_Rule_12_2:
    * -  Rule 12.2
      -  Required
      -  The right hand operand of a shift operator shall lie in the range zero to one less than the width in bits of the essential type of the left hand operand
      -  N/A
      -  `Rule 12.2 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_12_02.c>`_

         .. _MisraC_Rule_12_4:
    * -  Rule 12.4
      -  Advisory
      -  Evaluation of constant expressions should not lead to unsigned integer wrap-around
      -  N/A
      -  `Rule 12.4 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_12_04.c>`_

         .. _MisraC_Rule_12_5:
    * -  Rule 12.5
      -  Mandatory
      -  The sizeof operator shall not have an operand which is a function parameter declared as “array of type”
      -  N/A
      -  `Rule 12.5 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_12_05.c>`_

         .. _MisraC_Rule_13_1:
    * -  Rule 13.1
      -  Required
      -  Initializer lists shall not contain persistent side effects
      -  N/A
      -  | `Rule 13.1 example 1 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_13_01_1.c>`_
         | `Rule 13.1 example 2 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_13_01_2.c>`_

         .. _MisraC_Rule_13_2:
    * -  Rule 13.2
      -  Required
      -  The value of an expression and its persistent side effects shall be the same under all permitted evaluation orders
      -  N/A
      -  `Rule 13.2 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_13_02.c>`_

         .. _MisraC_Rule_13_3:
    * -  Rule 13.3
      -  Advisory
      -  A full expression containing an increment (++) or decrement (--) operator should have no other potential side effects other than that caused by the increment or decrement operator
      -  N/A
      -  `Rule 13.3 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_13_03.c>`_

         .. _MisraC_Rule_13_4:
    * -  Rule 13.4
      -  Advisory
      -  The result of an assignment operator should not be used
      -  N/A
      -  `Rule 13.4 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_13_04.c>`_

         .. _MisraC_Rule_13_5:
    * -  Rule 13.5
      -  Required
      -  The right hand operand of a logical && or || operator shall not contain persistent side effects
      -  `EXP10-C <https://wiki.sei.cmu.edu/confluence/display/c/EXP10-C.+Do+not+depend+on+the+order+of+evaluation+of+subexpressions+or+the+order+in+which+side+effects+take+place>`_
      -  | `Rule 13.5 example 1 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_13_05_1.c>`_
         | `Rule 13.5 example 2 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_13_05_2.c>`_

         .. _MisraC_Rule_13_6:
    * -  Rule 13.6
      -  Mandatory
      -  The operand of the sizeof operator shall not contain any expression which has potential side effects
      -  N/A
      -  `Rule 13.6 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_13_06.c>`_

         .. _MisraC_Rule_14_1:
    * -  Rule 14.1
      -  Required
      -  A loop counter shall not have essentially floating type
      -  N/A
      -  `Rule 14.1 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_14_01.c>`_

         .. _MisraC_Rule_14_2:
    * -  Rule 14.2
      -  Required
      -  A for loop shall be well-formed
      -  N/A
      -  `Rule 14.2 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_14_02.c>`_

         .. _MisraC_Rule_14_3:
    * -  Rule 14.3
      -  Required
      -  Controlling expressions shall not be invariant
      -  N/A
      -  `Rule 14.3 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_14_03.c>`_

         .. _MisraC_Rule_14_4:
    * -  Rule 14.4
      -  Required
      -  The controlling expression of an if statement and the controlling expression of an iteration-statement shall have essentially Boolean type
      -  N/A
      -  `Rule 14.4 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_14_04.c>`_

         .. _MisraC_Rule_15_2:
    * -  Rule 15.2
      -  Required
      -  The goto statement shall jump to a label declared later in the same function
      -  N/A
      -  `Rule 15.2 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_15_02.c>`_

         .. _MisraC_Rule_15_3:
    * -  Rule 15.3
      -  Required
      -  Any label referenced by a goto statement shall be declared in the same block, or in any block enclosing the goto statement
      -  N/A
      -  `Rule 15.3 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_15_03.c>`_

         .. _MisraC_Rule_15_6:
    * -  Rule 15.6
      -  Required
      -  The body of an iteration-statement or a selection-statement shall be a compound-statement
      -  `EXP19-C <https://wiki.sei.cmu.edu/confluence/display/c/EXP19-C.+Use+braces+for+the+body+of+an+if%2C+for%2C+or+while+statement>`_
      -  `Rule 15.6 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_15_06.c>`_

         .. _MisraC_Rule_15_7:
    * -  Rule 15.7
      -  Required
      -  All if else if constructs shall be terminated with an else statement
      -  N/A
      -  `Rule 15.7 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_15_07.c>`_

         .. _MisraC_Rule_16_1:
    * -  Rule 16.1
      -  Required
      -  All switch statements shall be well-formed
      -  N/A
      -  `Rule 16.1 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_16_01.c>`_

         .. _MisraC_Rule_16_2:
    * -  Rule 16.2
      -  Required
      -  A switch label shall only be used when the most closely-enclosing compound statement is the body of a switch statement
      -  `MSC20-C <https://wiki.sei.cmu.edu/confluence/display/c/MSC20-C.+Do+not+use+a+switch+statement+to+transfer+control+into+a+complex+block>`_
      -  `Rule 16.2 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_16_02.c>`_

         .. _MisraC_Rule_16_3:
    * -  Rule 16.3
      -  Required
      -  An unconditional break statement shall terminate every switch-clause
      -  N/A
      -  `Rule 16.3 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_16_03.c>`_

         .. _MisraC_Rule_16_4:
    * -  Rule 16.4
      -  Required
      -  Every switch statement shall have a default label
      -  N/A
      -  `Rule 16.4 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_16_04.c>`_

         .. _MisraC_Rule_16_5:
    * -  Rule 16.5
      -  Required
      -  A default label shall appear as either the first or the last switch label of a switch statement
      -  N/A
      -  `Rule 16.5 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_16_05.c>`_

         .. _MisraC_Rule_16_6:
    * -  Rule 16.6
      -  Required
      -  Every switch statement shall have at least two switch-clauses
      -  N/A
      -  `Rule 16.6 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_16_06.c>`_

         .. _MisraC_Rule_16_7:
    * -  Rule 16.7
      -  Required
      -  A switch-expression shall not have essentially Boolean type
      -  N/A
      -  `Rule 16.7 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_16_07.c>`_

         .. _MisraC_Rule_17_1:
    * -  Rule 17.1
      -  Required
      -  The features of <stdarg.h> shall not be used
      -  `ERR00-C <https://wiki.sei.cmu.edu/confluence/display/c/ERR00-C.+Adopt+and+implement+a+consistent+and+comprehensive+error-handling+policy>`_
      -  `Rule 17.1 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_17_01.c>`_

         .. _MisraC_Rule_17_2:
    * -  Rule 17.2
      -  Required
      -  Functions shall not call themselves, either directly or indirectly
      -  `MEM05-C <https://wiki.sei.cmu.edu/confluence/display/c/MEM05-C.+Avoid+large+stack+allocations>`_
      -  `Rule 17.2 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_17_02.c>`_

         .. _MisraC_Rule_17_3:
    * -  Rule 17.3
      -  Mandatory
      -  A function shall not be declared implicitly
      -  N/A
      -  `Rule 17.3 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_17_03.c>`_

         .. _MisraC_Rule_17_4:
    * -  Rule 17.4
      -  Mandatory
      -  All exit paths from a function with non-void return type shall have an explicit return statement with an expression
      -  N/A
      -  `Rule 17.4 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_17_04.c>`_

         .. _MisraC_Rule_17_5:
    * -  Rule 17.5
      -  Advisory
      -  The function argument corresponding to a parameter declared to have an array type shall have an appropriate number of elements
      -  N/A
      -  `Rule 17.5 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_17_05.c>`_

         .. _MisraC_Rule_17_6:
    * -  Rule 17.6
      -  Mandatory
      -  The declaration of an array parameter shall not contain the static keyword between the [ ]
      -  N/A
      -  `Rule 17.6 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_17_06.c>`_

         .. _MisraC_Rule_17_7:
    * -  Rule 17.7
      -  Required
      -  The value returned by a function having non-void return type shall be used
      -  N/A
      -  `Rule 17.7 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_17_07.c>`_

         .. _MisraC_Rule_18_1:
    * -  Rule 18.1
      -  Required
      -  A pointer resulting from arithmetic on a pointer operand shall address an element of the same array as that pointer operand
      -  `EXP08-C <https://wiki.sei.cmu.edu/confluence/display/c/EXP08-C.+Ensure+pointer+arithmetic+is+used+correctly>`_
      -  `Rule 18.1 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_18_01.c>`_

         .. _MisraC_Rule_18_2:
    * -  Rule 18.2
      -  Required
      -  Subtraction between pointers shall only be applied to pointers that address elements of the same array
      -  `EXP08-C <https://wiki.sei.cmu.edu/confluence/display/c/EXP08-C.+Ensure+pointer+arithmetic+is+used+correctly>`_
      -  `Rule 18.2 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_18_02.c>`_

         .. _MisraC_Rule_18_3:
    * -  Rule 18.3
      -  Required
      -  The relational operators >, >=, < and <= shall not be applied to objects of pointer type except where they point into the same object
      -  `EXP08-C <https://wiki.sei.cmu.edu/confluence/display/c/EXP08-C.+Ensure+pointer+arithmetic+is+used+correctly>`_
      -  `Rule 18.3 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_18_03.c>`_

         .. _MisraC_Rule_18_5:
    * -  Rule 18.5
      -  Advisory
      -  Declarations should contain no more than two levels of pointer nesting
      -  N/A
      -  `Rule 18.5 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_18_05.c>`_

         .. _MisraC_Rule_18_6:
    * -  Rule 18.6
      -  Required
      -  The address of an object with automatic storage shall not be copied to another object that persists after the first object has ceased to exist
      -  N/A
      -  | `Rule 18.6 example 1 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_18_06_1.c>`_
         | `Rule 18.6 example 2 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_18_06_2.c>`_

         .. _MisraC_Rule_18_8:
    * -  Rule 18.8
      -  Required
      -  Variable-length array types shall not be used
      -  N/A
      -  `Rule 18.8 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_18_08.c>`_

         .. _MisraC_Rule_19_1:
    * -  Rule 19.1
      -  Mandatory
      -  An object shall not be assigned or copied to an overlapping object
      -  N/A
      -  `Rule 19.1 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_19_01.c>`_

         .. _MisraC_Rule_20_2:
    * -  Rule 20.2
      -  Required
      -  The ', or \ characters and the /* or // character sequences shall not occur in a header file name"
      -  N/A
      -  `Rule 20.2 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_20_02.c>`_

         .. _MisraC_Rule_20_3:
    * -  Rule 20.3
      -  Required
      -  The #include directive shall be followed by either a <filename> or "filename" sequence
      -  N/A
      -  `Rule 20.3 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_20_03.c>`_

         .. _MisraC_Rule_20_4:
    * -  Rule 20.4
      -  Required
      -  A macro shall not be defined with the same name as a keyword
      -  N/A
      -  `Rule 20.4 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_20_04.c>`_

         .. _MisraC_Rule_20_7:
    * -  Rule 20.7
      -  Required
      -  Expressions resulting from the expansion of macro parameters shall be enclosed in parentheses
      -  `PRE01-C <https://wiki.sei.cmu.edu/confluence/display/c/PRE01-C.+Use+parentheses+within+macros+around+parameter+names>`_
      -  `Rule 20.7 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_20_07.c>`_

         .. _MisraC_Rule_20_8:
    * -  Rule 20.8
      -  Required
      -  The controlling expression of a #if or #elif preprocessing directive shall evaluate to 0 or 1
      -  N/A
      -  `Rule 20.8 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_20_08.c>`_

         .. _MisraC_Rule_20_9:
    * -  Rule 20.9
      -  Required
      -  All identifiers used in the controlling expression of #if or #elif preprocessing directives shall be #defined before evaluation
      -  N/A
      -  `Rule 20.9 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_20_09.c>`_

         .. _MisraC_Rule_20_11:
    * -  Rule 20.11
      -  Required
      -  A macro parameter immediately following a # operator shall not immediately be followed by a ## operator
      -  N/A
      -  `Rule 20.11 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_20_11.c>`_

         .. _MisraC_Rule_20_12:
    * -  Rule 20.12
      -  Required
      -  A macro parameter used as an operand to the # or ## operators, which is itself subject to further macro replacement, shall only be used as an operand to these operators
      -  N/A
      -  `Rule 20.12 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_20_12.c>`_

         .. _MisraC_Rule_20_13:
    * -  Rule 20.13
      -  Required
      -  A line whose first token is # shall be a valid preprocessing directive
      -  N/A
      -  `Rule 20.13 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_20_13.c>`_

         .. _MisraC_Rule_20_14:
    * -  Rule 20.14
      -  Required
      -  All #else, #elif and #endif preprocessor directives shall reside in the same file as the #if, #ifdef or #ifndef directive to which they are related
      -  N/A
      -  `Rule 20.14 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_20_14.c>`_

         .. _MisraC_Rule_21_1:
    * -  Rule 21.1
      -  Required
      -  #define and #undef shall not be used on a reserved identifier or reserved macro name
      -  N/A
      -  `Rule 21.1 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_21_01.c>`_

         .. _MisraC_Rule_21_2:
    * -  Rule 21.2
      -  Required
      -  A reserved identifier or macro name shall not be declared
      -  N/A
      -  `Rule 21.2 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_21_02.c>`_

         .. _MisraC_Rule_21_3:
    * -  Rule 21.3
      -  Required
      -  The memory allocation and deallocation functions of <stdlib.h> shall not be used
      -  `MSC24-C <https://wiki.sei.cmu.edu/confluence/display/c/MSC24-C.+Do+not+use+deprecated+or+obsolescent+functions>`_
      -  `Rule 21.3 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_21_03.c>`_

         .. _MisraC_Rule_21_4:
    * -  Rule 21.4
      -  Required
      -  The standard header file <setjmp.h> shall not be used
      -  N/A
      -  `Rule 21.4 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_21_04.c>`_

         .. _MisraC_Rule_21_6:
    * -  Rule 21.6
      -  Required
      -  The Standard Library input/output functions shall not be used
      -  N/A
      -  `Rule 21.6 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_21_06.c>`_

         .. _MisraC_Rule_21_7:
    * -  Rule 21.7
      -  Required
      -  The atof, atoi, atol and atoll functions of <stdlib.h> shall not be used
      -  N/A
      -  `Rule 21.7 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_21_07.c>`_

         .. _MisraC_Rule_21_9:
    * -  Rule 21.9
      -  Required
      -  The library functions bsearch and qsort of <stdlib.h> shall not be used
      -  N/A
      -  `Rule 21.9 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_21_09.c>`_

         .. _MisraC_Rule_21_11:
    * -  Rule 21.11
      -  Required
      -  The standard header file <tgmath.h> shall not be used
      -  N/A
      -  `Rule 21.11 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_21_11.c>`_

         .. _MisraC_Rule_21_12:
    * -  Rule 21.12
      -  Advisory
      -  The exception handling features of <fenv.h> should not be used
      -  N/A
      -  `Rule 21.12 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_21_12.c>`_

         .. _MisraC_Rule_21_13:
    * -  Rule 21.13
      -  Mandatory
      -  Any value passed to a function in <ctype.h> shall be representable as an unsigned char or be the value EO
      -  N/A
      -  `Rule 21.13 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_21_13.c>`_

         .. _MisraC_Rule_21_14:
    * -  Rule 21.14
      -  Required
      -  The Standard Library function memcmp shall not be used to compare null terminated strings
      -  N/A
      -  `Rule 21.14 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_21_14.c>`_

         .. _MisraC_Rule_21_15:
    * -  Rule 21.15
      -  Required
      -  The pointer arguments to the Standard Library functions memcpy, memmove and memcmp shall be pointers to qualified or unqualified versions of compatible types
      -  N/A
      -  `Rule 21.15 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_21_15.c>`_

         .. _MisraC_Rule_21_16:
    * -  Rule 21.16
      -  Required
      -  The pointer arguments to the Standard Library function memcmp shall point to either a pointer type, an essentially signed type, an essentially unsigned type, an essentially Boolean type or an essentially enum type
      -  N/A
      -  `Rule 21.16 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_21_16.c>`_

         .. _MisraC_Rule_21_17:
    * -  Rule 21.17
      -  Mandatory
      -  Use of the string handling functions from <string.h> shall not result in accesses beyond the bounds of the objects referenced by their pointer parameters
      -  N/A
      -  `Rule 21.17 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_21_17.c>`_

         .. _MisraC_Rule_21_18:
    * -  Rule 21.18
      -  Mandatory
      -  The size_t argument passed to any function in <string.h> shall have an appropriate value
      -  N/A
      -  `Rule 21.18 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_21_18.c>`_

         .. _MisraC_Rule_21_19:
    * -  Rule 21.19
      -  Mandatory
      -  The pointers returned by the Standard Library functions localeconv, getenv, setlocale or, strerror shall only be used as if they have pointer to const-qualified type
      -  N/A
      -  `Rule 21.19 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_21_19.c>`_

         .. _MisraC_Rule_21_20:
    * -  Rule 21.20
      -  Mandatory
      -  The pointer returned by the Standard Library functions asctime, ctime, gmtime, localtime, localeconv, getenv, setlocale or strerror shall not be used following a subsequent call to the same function
      -  N/A
      -  `Rule 21.20 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_21_20.c>`_

         .. _MisraC_Rule_22_1:
    * -  Rule 22.1
      -  Required
      -  All resources obtained dynamically by means of Standard Library functions shall be explicitly released
      -  N/A
      -  `Rule 22.1 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_22_01.c>`_

         .. _MisraC_Rule_22_2:
    * -  Rule 22.2
      -  Mandatory
      -  A block of memory shall only be freed if it was allocated by means of a Standard Library function
      -  N/A
      -  `Rule 22.2 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_22_02.c>`_

         .. _MisraC_Rule_22_3:
    * -  Rule 22.3
      -  Required
      -  The same file shall not be open for read and write access at the same time on different streams
      -  N/A
      -  `Rule 22.3 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_22_03.c>`_

         .. _MisraC_Rule_22_4:
    * -  Rule 22.4
      -  Mandatory
      -  There shall be no attempt to write to a stream which has been opened as read-only
      -  N/A
      -  `Rule 22.4 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_22_04.c>`_

         .. _MisraC_Rule_22_5:
    * -  Rule 22.5
      -  Mandatory
      -  A pointer to a FILE object shall not be dereferenced
      -  N/A
      -  `Rule 22.5 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_22_05.c>`_

         .. _MisraC_Rule_22_6:
    * -  Rule 22.6
      -  Mandatory
      -  The value of a pointer to a FILE shall not be used after the associated stream has been closed
      -  N/A
      -  `Rule 22.6 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_22_06.c>`_

         .. _MisraC_Rule_22_7:
    * -  Rule 22.7
      -  Required
      -  The macro EOF shall only be compared with the unmodified return value from any Standard Library function capable of returning EOF
      -  N/A
      -  `Rule 22.7 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_22_07.c>`_

         .. _MisraC_Rule_22_8:
    * -  Rule 22.8
      -  Required
      -  The value of errno shall be set to zero prior to a call to an errno-setting-function
      -  N/A
      -  `Rule 22.8 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_22_08.c>`_

         .. _MisraC_Rule_22_9:
    * -  Rule 22.9
      -  Required
      -  The value of errno shall be tested against zero after calling an errno-setting-function
      -  N/A
      -  `Rule 22.9 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_22_09.c>`_

         .. _MisraC_Rule_22_10:
    * -  Rule 22.10
      -  Required
      -  The value of errno shall only be tested when the last function to be called was an errno-setting-function
      -  N/A
      -  `Rule 22.10 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_22_10.c>`_

Additional rules
****************

Rule A.1: Conditional Compilation
=================================

Severity
--------

Required

Description
-----------

Do not conditionally compile function declarations in header files.  Do not
conditionally compile structure declarations in header files.  You may
conditionally exclude fields within structure definitions to avoid wasting
memory when the feature they support is not enabled.

Rationale
---------

Excluding declarations from the header based on compile-time options may prevent
their documentation from being generated. Their absence also prevents use of
``if (IS_ENABLED(CONFIG_FOO)) {}`` as an alternative to preprocessor
conditionals when the code path should change based on the selected options.

.. _coding_guideline_inclusive_language:

Rule A.2: Inclusive Language
============================

Severity
--------

Required

Description
-----------

Do not introduce new usage of offensive terms listed below. This rule applies
but is not limited to source code, comments, documentation, and branch names.
Replacement terms may vary by area or subsystem, but should aim to follow
updated industry standards when possible.

Exceptions are allowed for maintaining existing implementations or adding new
implementations of industry standard specifications governed externally to the
Zephyr Project.

Existing usage is recommended to change as soon as updated industry standard
specifications become available or new terms are publicly announced by the
governing body, or immediately if no specifications apply.

.. list-table::
   :header-rows: 1

   * - Offensive Terms
     - Recommended Replacements

   * - ``{master,leader} / slave``
     - - ``{primary,main} / {secondary,replica}``
       - ``{initiator,requester} / {target,responder}``
       - ``{controller,host} / {device,worker,proxy,target}``
       - ``director / performer``
       - ``central / peripheral``

   * - ``blacklist / whitelist``
     - * ``denylist / allowlist``
       * ``blocklist / allowlist``
       * ``rejectlist / acceptlist``

   * - ``grandfather policy``
     - * ``legacy``

   * - ``sanity``
     - * ``coherence``
       * ``confidence``


Rationale
---------

Offensive terms do not create an inclusive community environment and therefore
violate the Zephyr Project `Code of Conduct`_. This coding rule was inspired by
a similar rule in `Linux`_.

.. _Code of Conduct: https://github.com/zephyrproject-rtos/zephyr/blob/main/CODE_OF_CONDUCT.md
.. _Linux: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=49decddd39e5f6132ccd7d9fdc3d7c470b0061bb

Status
------

Related GitHub Issues and Pull Requests are tagged with the `Inclusive Language Label`_.

.. list-table::
   :header-rows: 1

   * - Area
     - Selected Replacements
     - Status

   * - :ref:`bluetooth_api`
     - See `Bluetooth Appropriate Language Mapping Tables`_
     -

   * - CAN
     - This `CAN in Automation Inclusive Language news post`_ has a list of general
       recommendations. See `CAN in Automation Inclusive Language`_ for terms to
       be used in specification document updates.
     -

   * - eSPI
     - * ``master / slave`` => ``controller / target``
     - Refer to `eSPI Specification`_ for new terminology

   * - gPTP
     - * ``master / slave`` => TBD
     -

   * - :ref:`i2c_api`
     - * ``master / slave`` => TBD
     - NXP publishes the `I2C Specification`_ and has selected ``controller /
       target`` as replacement terms, but the timing to publish an announcement
       or new specification is TBD. Zephyr will update I2C when replacement
       terminology is confirmed by a public announcement or updated
       specification.

       See :github:`Zephyr issue 27033 <27033>`.

   * - :ref:`i2s_api`
     - * ``master / slave`` => TBD
     -

   * - SMP/AMP
     - * ``master / slave`` => TBD
     -

   * - :ref:`spi_api`
     - * ``master / slave`` => ``controller / peripheral``
       * ``MOSI / MISO / SS`` => ``SDO / SDI / CS``
     - The Open Source Hardware Association has selected these replacement
       terms. See `OSHWA Resolution to Redefine SPI Signal Names`_

   * - :ref:`twister_script`
     - * ``platform_whitelist`` => ``platform_allow``
       * ``sanitycheck`` => ``twister``
     -

.. _Inclusive Language Label: https://github.com/zephyrproject-rtos/zephyr/issues?q=label%3A%22Inclusive+Language%22
.. _I2C Specification: https://www.nxp.com/docs/en/user-guide/UM10204.pdf
.. _Bluetooth Appropriate Language Mapping Tables: https://specificationrefs.bluetooth.com/language-mapping/Appropriate_Language_Mapping_Table.pdf
.. _OSHWA Resolution to Redefine SPI Signal Names: https://www.oshwa.org/a-resolution-to-redefine-spi-signal-names/
.. _CAN in Automation Inclusive Language news post: https://www.can-cia.org/news/archive/view/?tx_news_pi1%5Bnews%5D=699&tx_news_pi1%5Bday%5D=6&tx_news_pi1%5Bmonth%5D=12&tx_news_pi1%5Byear%5D=2020&cHash=784e79eb438141179386cf7c29ed9438
.. _CAN in Automation Inclusive Language: https://can-newsletter.org/canopen/categories/
.. _eSPI Specification: https://downloadmirror.intel.com/27055/327432%20espi_base_specification%20R1-5.pdf


Rule A.3: Macro name collisions
===============================

Severity
--------

Required

Description
-----------

Macros with commonly used names such as  ``MIN``, ``MAX``, ``ARRAY_SIZE``, must
not be modified or protected to avoid name collisions with other
implementations. In particular, they must not be prefixed to place them in a
Zephyr-specific namespace, re-defined using ``#undef``, or conditionally
excluded from compilation using ``#ifndef``.  Instead, if a conflict arises with
an existing definition originating from a :ref:`module <modules>`, the module's
code itself needs to be modified (ideally upstream, alternatively via a change
in Zephyr's own fork).
This rule applies to Zephyr as a project in general, regardless of the time of
introduction of the macro or its current name in the tree. If a macro name is
commonly used in several other well-known open source projects then the
implementation in Zephyr should use that name. While there is a subjective and
non-measurable component to what "commonly used" means, the ultimate goal is
to offer users familiar macros.
Finally, this rule applies to inter-module name collisions as well: in that case
both modules, prior to their inclusion, should be modified to use
module-specific versions of the macro name that collides.

Rationale
---------

Zephyr is an RTOS that comes with additional functionality and dependencies in
the form of modules. Those modules are typically independent projects that may
use macro names that can conflict with other modules or with Zephyr itself.
Since, in the context of this documentation, Zephyr is considered the central or
main project, it should implement the non-namespaced versions of the
macros. Given that Zephyr uses a fork of the corresponding upstream for each
module, it is always possible to patch the macro implementation in each module
to avoid collisions.

.. _coding_guideline_libc_usage_restrictions_in_zephyr_kernel:

Rule A.4: C Standard Library Usage Restrictions in Zephyr Kernel
================================================================

Severity
--------

Required

Description
-----------

The use of the C standard library functions and macros in the Zephyr kernel
shall be limited to the following functions and macros from the ISO/IEC
9899:2011 standard, also known as C11, and their extensions:

.. csv-table:: List of allowed libc functions and macros in the Zephyr kernel
   :header: Function,Source
   :widths: auto

   abort(),ISO/IEC 9899:2011
   abs(),ISO/IEC 9899:2011
   aligned_alloc(),ISO/IEC 9899:2011
   assert(),ISO/IEC 9899:2011
   atoi(),ISO/IEC 9899:2011
   bsearch(),ISO/IEC 9899:2011
   calloc(),ISO/IEC 9899:2011
   exit(),ISO/IEC 9899:2011
   fprintf(),ISO/IEC 9899:2011
   fputc(),ISO/IEC 9899:2011
   fputs(),ISO/IEC 9899:2011
   free(),ISO/IEC 9899:2011
   fwrite(),ISO/IEC 9899:2011
   gmtime(),ISO/IEC 9899:2011
   isalnum(),ISO/IEC 9899:2011
   isalpha(),ISO/IEC 9899:2011
   iscntrl(),ISO/IEC 9899:2011
   isdigit(),ISO/IEC 9899:2011
   isgraph(),ISO/IEC 9899:2011
   isprint(),ISO/IEC 9899:2011
   isspace(),ISO/IEC 9899:2011
   isupper(),ISO/IEC 9899:2011
   isxdigit(),ISO/IEC 9899:2011
   labs(),ISO/IEC 9899:2011
   llabs(),ISO/IEC 9899:2011
   malloc(),ISO/IEC 9899:2011
   memchr(),ISO/IEC 9899:2011
   memcmp(),ISO/IEC 9899:2011
   memcpy(),ISO/IEC 9899:2011
   memmove(),ISO/IEC 9899:2011
   memset(),ISO/IEC 9899:2011
   perror(),ISO/IEC 9899:2011
   printf(),ISO/IEC 9899:2011
   putc(),ISO/IEC 9899:2011
   putchar(),ISO/IEC 9899:2011
   puts(),ISO/IEC 9899:2011
   qsort(),ISO/IEC 9899:2011
   rand(),ISO/IEC 9899:2011
   realloc(),ISO/IEC 9899:2011
   snprintf(),ISO/IEC 9899:2011
   sprintf(),ISO/IEC 9899:2011
   sqrt(),ISO/IEC 9899:2011
   sqrtf(),ISO/IEC 9899:2011
   srand(),ISO/IEC 9899:2011
   strcat(),ISO/IEC 9899:2011
   strchr(),ISO/IEC 9899:2011
   strcmp(),ISO/IEC 9899:2011
   strcpy(),ISO/IEC 9899:2011
   strcspn(),ISO/IEC 9899:2011
   strerror(),ISO/IEC 9899:2011
   strlen(),ISO/IEC 9899:2011
   strncat(),ISO/IEC 9899:2011
   strncmp(),ISO/IEC 9899:2011
   strncpy(),ISO/IEC 9899:2011
   `strnlen()`_,POSIX.1-2008
   strrchr(),ISO/IEC 9899:2011
   strspn(),ISO/IEC 9899:2011
   strstr(),ISO/IEC 9899:2011
   strtol(),ISO/IEC 9899:2011
   strtoll(),ISO/IEC 9899:2011
   strtoul(),ISO/IEC 9899:2011
   strtoull(),ISO/IEC 9899:2011
   time(),ISO/IEC 9899:2011
   tolower(),ISO/IEC 9899:2011
   toupper(),ISO/IEC 9899:2011
   vfprintf(),ISO/IEC 9899:2011
   vprintf(),ISO/IEC 9899:2011
   vsnprintf(),ISO/IEC 9899:2011
   vsprintf(),ISO/IEC 9899:2011

All of the functions listed above must be implemented by the
:ref:`minimal libc <c_library_minimal>` to ensure that the Zephyr kernel can
build with the minimal libc.

In addition, any functions from the above list that are not part of the
ISO/IEC 9899:2011 standard must be implemented by the
:ref:`common libc <c_library_common>` to ensure their availability across
multiple C standard libraries.

Introducing new C standard library functions to the Zephyr kernel is allowed
with justification given that the above requirements are satisfied.

Note that the use of the functions listed above are subject to secure and safe
coding practices and it should not be assumed that their use in the Zephyr
kernel is unconditionally permitted by being listed in this rule.

The "Zephyr kernel" in this context consists of the following components:

* Kernel (:file:`kernel`)
* OS Library (:file:`lib/os`)
* Architecture Port (:file:`arch`)
* Logging Subsystem (:file:`subsys/logging`)

Rationale
---------

Zephyr kernel must be able to build with the
:ref:`minimal libc <c_library_minimal>`, a limited C standard library
implementation that is part of the Zephyr RTOS and maintained by the Zephyr
Project, to allow self-contained testing and verification of the kernel and
core OS services.

In order to ensure that the Zephyr kernel can build with the minimal libc, it
is necessary to restrict the use of the C standard library functions and macros
in the Zephyr kernel to the functions and macros that are available as part of
the minimal libc.

Rule A.5: C Standard Library Usage Restrictions in Zephyr Codebase
==================================================================

Severity
--------

Required

Description
-----------

The use of the C standard library functions and macros in the Zephyr codebase
shall be limited to the functions, excluding the Annex K "Bounds-checking
interfaces", from the ISO/IEC 9899:2011 standard, also known as C11, unless
exempted by this rule.

The "Zephyr codebase" in this context refers to all embedded source code files committed
to the `main Zephyr repository`_, except the Zephyr kernel as defined by the
:ref:`coding_guideline_libc_usage_restrictions_in_zephyr_kernel`.
With embedded source code we refer to code which is meant to be executed in embedded
targets, and therefore excludes host tooling, and code specific for the
:ref:`native <boards_posix>` test targets.

The following non-ISO 9899:2011, hereinafter referred to as non-standard,
functions and macros are exempt from this rule and allowed to be used in the
Zephyr codebase:

.. csv-table:: List of allowed non-standard libc functions
   :header: Function,Source
   :widths: auto

   `gmtime_r()`_,POSIX.1-2001
   `strnlen()`_,POSIX.1-2008
   `strtok_r()`_,POSIX.1-2001

All non-standard functions and macros listed above must be implemented by the
:ref:`common libc <c_library_common>` in order to make sure that these
functions can be made available when using a C standard library that does not
implement these functions.

Adding a new non-standard function from common C standard libraries to the
above list is allowed with justification, given that the above requirement is
satisfied. However, when there exists a standard function that is functionally
equivalent, the standard function shall be used.

Rationale
---------

Some C standard libraries, such as Newlib and Picolibc, include additional
functions and macros that are defined by the standards and de-facto standards
that extend the ISO C standard (e.g. POSIX, Linux).

The ISO/IEC 9899:2011 standard does not require C compiler toolchains to
include the support for these non-standard functions, and therefore using
these functions can lead to compatibility issues with the third-party
toolchains that come with their own C standard libraries.

.. _main Zephyr repository: https://github.com/zephyrproject-rtos/zephyr
.. _gmtime_r(): https://pubs.opengroup.org/onlinepubs/9699919799/functions/gmtime_r.html
.. _strnlen(): https://pubs.opengroup.org/onlinepubs/9699919799/functions/strlen.html
.. _strtok_r(): https://pubs.opengroup.org/onlinepubs/9699919799/functions/strtok.html

Part 3

한국어 전문 번역

Coding Guidelines

Project TSC와 Safety Committee는 codebase의 품질과 일관성을 높이기 위해 Coding Guidelines라고 부르는 coding rule 집합을 단계적이고 점진적으로 준수하기로 합의했습니다.

단계별 적용

Stage I(완료): 규칙을 따르고 참조할 수 있지만 강제하지 않습니다. CI가 검사하지 않으며 위반만을 이유로 reviewer나 approver가 Pull Request를 막을 수 없습니다.
Stage II: codebase의 제한된 범위에서 강제를 시작합니다. 초기 범위는 safety certification 대상이며 전체에 쉽게 적용할 수 있는 규칙은 그 범위로 제한하지 않습니다. Tooling, CI 설정, enforcement strategy가 필요합니다.
Stage III: 앞 단계의 경험을 바탕으로 coding guideline을 다시 검토하고 선택한 규칙을 다듬습니다.
Stage IV: 더 넓은 codebase로 강제를 확대합니다. 정당한 근거가 있으면 일부 영역에 예외를 줄 수 있지만 TSC 승인이 필요합니다.

Coding guideline rule은 GitHub issue 또는 RFC를 제출해 언제든 제거하거나 변경할 수 있습니다.

현재는 Stage II 진입 조건을 검토하고 있습니다. Tooling을 평가 중이며 CI 설정과 enforcement strategy를 준비하고 있습니다.

주요 규칙

주요 규칙은 MISRA-C:2012의 부분집합입니다. 아래 표는 선택된 directive와 rule 147개의 심각도, 규칙 전문 번역, 대응 CERT C 규칙과 MISRA 공식 예제를 모두 보존합니다.

기존 Zephyr maintainer와 collaborator가 고용주 등 다른 경로로 MISRA-C:2012 사본을 구할 수 없다면 project가 제한된 수량을 제공할 수 있습니다. 필요 사유와 사본을 받은 뒤 예상하는 기여 내용을 [email protected]로 보내면 Safety Committee가 요청을 검토합니다.

MISRA C 2012	심각도	규칙 전문 번역	CERT C·공식 예제
`Dir 1.1`	필수	프로그램 출력이 의존하는 모든 구현 정의 동작을 문서화하고 이해해야 합니다.	MSC09-C Dir 1.1
`Dir 2.1`	필수	모든 소스 파일은 컴파일 오류 없이 컴파일되어야 합니다.	Dir 2.1
`Dir 3.1`	필수	모든 코드는 문서화된 요구 사항까지 추적할 수 있어야 합니다.	Dir 3.1
`Dir 4.1`	필수	런타임 실패를 최소화해야 합니다.	Dir 4.1
`Dir 4.2`	권고	어셈블리 언어를 사용한 모든 곳을 문서화하는 것이 좋습니다.	Dir 4.2
`Dir 4.4`	권고	코드 구간을 주석 처리한 채 남겨 두지 않는 것이 좋습니다.	MSC04-C Dir 4.4
`Dir 4.5`	권고	같은 이름 공간에서 가시성이 겹치는 식별자는 글자 모양만으로도 명확히 구별되는 것이 좋습니다.	DCL02-C Dir 4.5
`Dir 4.6`	권고	기본 수치형 대신 크기와 부호 여부를 나타내는 typedef를 사용하는 것이 좋습니다.	Dir 4.6
`Dir 4.7`	필수	함수가 오류 정보를 반환하면 그 정보를 반드시 검사해야 합니다.	Dir 4.7
`Dir 4.8`	권고	번역 단위 안에서 구조체나 공용체 포인터를 역참조하지 않는다면 객체 구현을 숨기는 것이 좋습니다.	DCL12-C Dir 4.8 example 1 Dir 4.8 example 2
`Dir 4.9`	권고	함수형 매크로와 함수를 서로 바꿔 쓸 수 있다면 함수를 우선 사용하는 것이 좋습니다.	PRE00-C Dir 4.9
`Dir 4.10`	필수	헤더 파일 내용이 두 번 이상 포함되지 않도록 예방 조치를 취해야 합니다.	PRE06-C Dir 4.10
`Dir 4.11`	필수	라이브러리 함수에 넘기는 값의 유효성을 검사해야 합니다.	Dir 4.11
`Dir 4.12`	필수	동적 메모리 할당을 사용하면 안 됩니다.	STR01-C Dir 4.12
`Dir 4.13`	권고	자원에 대한 연산을 제공하도록 설계된 함수는 적절한 순서로 호출하는 것이 좋습니다.	Dir 4.13
`Dir 4.14`	필수	외부 출처에서 받은 값의 유효성을 검사해야 합니다.	Dir 4.14
`Rule 1.2`	권고	언어 확장 기능을 사용하지 않는 것이 좋습니다.	MSC04-C Rule 1.2
`Rule 1.3`	필수	정의되지 않은 동작이나 치명적인 미지정 동작이 발생하면 안 됩니다.	Rule 1.3
`Rule 2.1`	필수	프로젝트에 도달할 수 없는 코드가 있으면 안 됩니다.	MSC07-C Rule 2.1 example 1 Rule 2.1 example 2
`Rule 2.2`	필수	죽은 코드가 있으면 안 됩니다.	MSC12-C Rule 2.2
`Rule 2.3`	권고	프로젝트에 사용하지 않는 형 선언을 두지 않는 것이 좋습니다.	Rule 2.3
`Rule 2.6`	권고	함수에 사용하지 않는 레이블 선언을 두지 않는 것이 좋습니다.	Rule 2.6
`Rule 2.7`	권고	함수에 사용하지 않는 매개변수를 두지 않는 것이 좋습니다.	Rule 2.7
`Rule 3.1`	필수	주석 안에 /* 또는 // 문자 시퀀스를 사용하면 안 됩니다.	MSC04-C Rule 3.1
`Rule 3.2`	필수	// 주석에서 줄 이어 붙이기를 사용하면 안 됩니다.	Rule 3.2
`Rule 4.1`	필수	8진수와 16진수 이스케이프 시퀀스를 명확히 끝내야 합니다.	MSC09-C Rule 4.1
`Rule 4.2`	권고	트라이그래프를 사용하지 않는 것이 좋습니다.	PRE07-C Rule 4.2
`Rule 5.1`	필수	외부 식별자는 서로 달라야 합니다.	DCL23-C Rule 5.1 example 1 Rule 5.1 example 2
`Rule 5.2`	필수	같은 범위와 이름 공간에 선언한 식별자는 서로 달라야 합니다.	DCL23-C Rule 5.2
`Rule 5.3`	필수	안쪽 범위의 식별자가 바깥 범위의 식별자를 가리면 안 됩니다.	DCL23-C Rule 5.3
`Rule 5.4`	필수	매크로 식별자는 서로 달라야 합니다.	DCL23-C Rule 5.4
`Rule 5.5`	필수	식별자는 매크로 이름과 달라야 합니다.	DCL23-C Rule 5.5
`Rule 5.6`	필수	typedef 이름은 고유한 식별자여야 합니다.	Rule 5.6
`Rule 5.7`	필수	태그 이름은 고유한 식별자여야 합니다.	Rule 5.7
`Rule 5.8`	필수	외부 연결을 갖는 객체나 함수를 정의하는 식별자는 고유해야 합니다.	Rule 5.8 example 1 Rule 5.8 example 2
`Rule 5.9`	권고	내부 연결을 갖는 객체나 함수를 정의하는 식별자도 고유하게 만드는 것이 좋습니다.	Rule 5.9 example 1 Rule 5.9 example 2
`Rule 6.1`	필수	비트 필드는 적절한 형으로만 선언해야 합니다.	INT14-C Rule 6.1
`Rule 6.2`	필수	이름 있는 1비트 비트 필드는 부호 있는 형이면 안 됩니다.	INT14-C Rule 6.2
`Rule 7.1`	필수	8진수 상수를 사용하면 안 됩니다.	DCL18-C Rule 7.1
`Rule 7.2`	필수	부호 없는 형으로 표현되는 모든 정수 상수에 u 또는 U 접미사를 붙여야 합니다.	Rule 7.2
`Rule 7.3`	필수	리터럴 접미사에 소문자 l을 사용하면 안 됩니다.	DCL16-C Rule 7.3
`Rule 7.4`	필수	객체 형이 const 한정 char 포인터가 아니면 문자열 리터럴을 그 객체에 대입하면 안 됩니다.	Rule 7.4
`Rule 8.1`	필수	형을 명시적으로 지정해야 합니다.	Rule 8.1
`Rule 8.2`	필수	함수 형은 이름 붙은 매개변수가 있는 프로토타입 형식이어야 합니다.	DCL20-C Rule 8.2
`Rule 8.3`	필수	한 객체나 함수의 모든 선언은 같은 이름과 형 한정자를 사용해야 합니다.	Rule 8.3
`Rule 8.4`	필수	외부 연결을 갖는 객체나 함수를 정의할 때 호환되는 선언이 보여야 합니다.	Rule 8.4
`Rule 8.5`	필수	외부 객체나 함수는 오직 한 파일에서 한 번만 선언해야 합니다.	Rule 8.5 example 1 Rule 8.5 example 2
`Rule 8.6`	필수	외부 연결 식별자는 정확히 하나의 외부 정의를 가져야 합니다.	Rule 8.6 example 1 Rule 8.6 example 2
`Rule 8.8`	필수	내부 연결을 갖는 객체와 함수의 모든 선언에 static 저장 클래스 지정자를 사용해야 합니다.	DCL15-C Rule 8.8
`Rule 8.9`	권고	식별자가 한 함수에서만 나타나는 객체는 블록 범위에 정의하는 것이 좋습니다.	DCL19-C Rule 8.9
`Rule 8.10`	필수	인라인 함수는 static 저장 클래스로 선언해야 합니다.	Rule 8.10
`Rule 8.12`	필수	열거자 목록에서 암시적으로 지정되는 열거 상수 값은 고유해야 합니다.	INT09-C Rule 8.12
`Rule 8.14`	필수	restrict 형 한정자를 사용하면 안 됩니다.	Rule 8.14
`Rule 9.1`	의무	자동 저장 기간 객체의 값은 설정하기 전에 읽으면 안 됩니다.	Rule 9.1
`Rule 9.2`	필수	집합체나 공용체의 초기화 목록은 중괄호로 감싸야 합니다.	Rule 9.2
`Rule 9.3`	필수	배열을 부분적으로 초기화하면 안 됩니다.	Rule 9.3
`Rule 9.4`	필수	객체의 한 원소를 두 번 이상 초기화하면 안 됩니다.	Rule 9.4
`Rule 9.5`	필수	지정 초기화자로 배열을 초기화하면 배열 크기를 명시해야 합니다.	Rule 9.5
`Rule 10.1`	필수	피연산자는 부적절한 본질적 형을 가지면 안 됩니다.	STR04-C Rule 10.1
`Rule 10.2`	필수	본질적으로 문자형인 표현식을 덧셈과 뺄셈에서 부적절하게 사용하면 안 됩니다.	STR04-C Rule 10.2
`Rule 10.3`	필수	표현식 값을 더 좁은 본질적 형이나 다른 본질적 형 범주의 객체에 대입하면 안 됩니다.	STR04-C Rule 10.3
`Rule 10.4`	필수	일반 산술 변환이 수행되는 연산자의 두 피연산자는 같은 본질적 형 범주여야 합니다.	STR04-C Rule 10.4
`Rule 10.5`	권고	표현식 값을 부적절한 본질적 형으로 캐스팅하지 않는 것이 좋습니다.	Rule 10.5
`Rule 10.6`	필수	복합 표현식 값을 더 넓은 본질적 형의 객체에 대입하면 안 됩니다.	INT02-C Rule 10.6
`Rule 10.7`	필수	일반 산술 변환 연산자의 한 피연산자가 복합 표현식이면 다른 피연산자는 더 넓은 본질적 형이면 안 됩니다.	INT02-C Rule 10.7
`Rule 10.8`	필수	복합 표현식 값을 다른 본질적 형 범주나 더 넓은 본질적 형으로 캐스팅하면 안 됩니다.	INT02-C Rule 10.8
`Rule 11.2`	필수	불완전 형 포인터와 다른 형 사이의 변환을 수행하면 안 됩니다.	Rule 11.2
`Rule 11.6`	필수	void 포인터와 산술형 사이에 캐스팅을 수행하면 안 됩니다.	Rule 11.6
`Rule 11.7`	필수	객체 포인터와 정수형이 아닌 산술형 사이에 캐스팅을 수행하면 안 됩니다.	Rule 11.7
`Rule 11.8`	필수	캐스팅으로 포인터가 가리키는 형의 const 또는 volatile 한정자를 제거하면 안 됩니다.	EXP05-C Rule 11.8
`Rule 11.9`	필수	정수 널 포인터 상수로는 NULL 매크로만 허용합니다.	Rule 11.9
`Rule 12.1`	권고	표현식 안 연산자의 우선순위를 명시적으로 드러내는 것이 좋습니다.	EXP00-C Rule 12.1
`Rule 12.2`	필수	시프트 연산자의 오른쪽 피연산자는 0부터 왼쪽 피연산자 본질적 형의 비트 너비보다 1 작은 값 사이여야 합니다.	Rule 12.2
`Rule 12.4`	권고	상수 표현식 평가가 부호 없는 정수 래핑을 일으키지 않는 것이 좋습니다.	Rule 12.4
`Rule 12.5`	의무	sizeof 연산자의 피연산자로 'type의 배열'로 선언된 함수 매개변수를 사용하면 안 됩니다.	Rule 12.5
`Rule 13.1`	필수	초기화 목록에 지속적인 부수 효과가 있으면 안 됩니다.	Rule 13.1 example 1 Rule 13.1 example 2
`Rule 13.2`	필수	허용된 모든 평가 순서에서 표현식 값과 지속적인 부수 효과가 같아야 합니다.	Rule 13.2
`Rule 13.3`	권고	증가 또는 감소 연산자가 있는 완전 표현식에는 그 연산이 만드는 것 외의 잠재적 부수 효과를 두지 않는 것이 좋습니다.	Rule 13.3
`Rule 13.4`	권고	대입 연산자의 결과를 사용하지 않는 것이 좋습니다.	Rule 13.4
`Rule 13.5`	필수	논리 && 또는 \|\| 연산자의 오른쪽 피연산자에 지속적인 부수 효과가 있으면 안 됩니다.	EXP10-C Rule 13.5 example 1 Rule 13.5 example 2
`Rule 13.6`	의무	sizeof 연산자의 피연산자에 잠재적 부수 효과가 있는 표현식을 넣으면 안 됩니다.	Rule 13.6
`Rule 14.1`	필수	루프 카운터는 본질적으로 부동소수점형이면 안 됩니다.	Rule 14.1
`Rule 14.2`	필수	for 루프는 올바른 형식을 갖춰야 합니다.	Rule 14.2
`Rule 14.3`	필수	제어 표현식은 불변이면 안 됩니다.	Rule 14.3
`Rule 14.4`	필수	if 문과 반복문의 제어 표현식은 본질적으로 불리언형이어야 합니다.	Rule 14.4
`Rule 15.2`	필수	goto 문은 같은 함수에서 뒤에 선언된 레이블로만 이동해야 합니다.	Rule 15.2
`Rule 15.3`	필수	goto가 참조하는 레이블은 같은 블록이나 goto를 감싼 블록에 선언되어야 합니다.	Rule 15.3
`Rule 15.6`	필수	반복문이나 선택문의 본문은 복합문이어야 합니다.	EXP19-C Rule 15.6
`Rule 15.7`	필수	모든 if-else-if 구조는 else 문으로 끝나야 합니다.	Rule 15.7
`Rule 16.1`	필수	모든 switch 문은 올바른 형식을 갖춰야 합니다.	Rule 16.1
`Rule 16.2`	필수	switch 레이블은 가장 가까이 감싼 복합문이 switch 문의 본문일 때만 사용해야 합니다.	MSC20-C Rule 16.2
`Rule 16.3`	필수	모든 switch 절은 무조건 break 문으로 끝나야 합니다.	Rule 16.3
`Rule 16.4`	필수	모든 switch 문에 default 레이블이 있어야 합니다.	Rule 16.4
`Rule 16.5`	필수	default 레이블은 switch 문의 첫 번째 또는 마지막 레이블이어야 합니다.	Rule 16.5
`Rule 16.6`	필수	모든 switch 문은 switch 절을 두 개 이상 가져야 합니다.	Rule 16.6
`Rule 16.7`	필수	switch 표현식은 본질적으로 불리언형이면 안 됩니다.	Rule 16.7
`Rule 17.1`	필수	<stdarg.h> 기능을 사용하면 안 됩니다.	ERR00-C Rule 17.1
`Rule 17.2`	필수	함수는 직접 또는 간접으로 자기 자신을 호출하면 안 됩니다.	MEM05-C Rule 17.2
`Rule 17.3`	의무	함수를 암시적으로 선언하면 안 됩니다.	Rule 17.3
`Rule 17.4`	의무	void가 아닌 반환형 함수의 모든 종료 경로에는 표현식이 있는 명시적 return 문이 있어야 합니다.	Rule 17.4
`Rule 17.5`	권고	배열형 매개변수에 대응하는 함수 인수는 적절한 수의 원소를 가지는 것이 좋습니다.	Rule 17.5
`Rule 17.6`	의무	배열 매개변수 선언의 대괄호 사이에 static 키워드를 넣으면 안 됩니다.	Rule 17.6
`Rule 17.7`	필수	void가 아닌 반환형 함수가 반환한 값을 사용해야 합니다.	Rule 17.7
`Rule 18.1`	필수	포인터 산술 결과 포인터는 원래 포인터와 같은 배열의 원소를 가리켜야 합니다.	EXP08-C Rule 18.1
`Rule 18.2`	필수	포인터 뺄셈은 같은 배열 원소를 가리키는 포인터끼리만 수행해야 합니다.	EXP08-C Rule 18.2
`Rule 18.3`	필수	같은 객체 안을 가리키는 경우가 아니면 포인터형 객체에 관계 연산자 >, >=, <, <=를 적용하면 안 됩니다.	EXP08-C Rule 18.3
`Rule 18.5`	권고	선언에서 포인터 중첩은 두 단계를 넘지 않는 것이 좋습니다.	Rule 18.5
`Rule 18.6`	필수	자동 저장 기간 객체의 주소를 그 객체가 사라진 뒤에도 남는 다른 객체에 복사하면 안 됩니다.	Rule 18.6 example 1 Rule 18.6 example 2
`Rule 18.8`	필수	가변 길이 배열형을 사용하면 안 됩니다.	Rule 18.8
`Rule 19.1`	의무	객체를 메모리 영역이 겹치는 객체에 대입하거나 복사하면 안 됩니다.	Rule 19.1
`Rule 20.2`	필수	헤더 파일 이름에 ', \ 문자나 /*, // 문자 시퀀스가 나타나면 안 됩니다.	Rule 20.2
`Rule 20.3`	필수	#include 지시문 뒤에는 <filename> 또는 "filename" 시퀀스가 와야 합니다.	Rule 20.3
`Rule 20.4`	필수	키워드와 같은 이름으로 매크로를 정의하면 안 됩니다.	Rule 20.4
`Rule 20.7`	필수	매크로 매개변수 확장으로 생기는 표현식은 괄호로 감싸야 합니다.	PRE01-C Rule 20.7
`Rule 20.8`	필수	#if 또는 #elif 전처리 지시문의 제어 표현식은 0 또는 1로 평가되어야 합니다.	Rule 20.8
`Rule 20.9`	필수	#if 또는 #elif 제어 표현식에 쓰는 모든 식별자는 평가 전에 #define으로 정의되어야 합니다.	Rule 20.9
`Rule 20.11`	필수	# 연산자 바로 뒤의 매크로 매개변수 다음에 ## 연산자가 바로 오면 안 됩니다.	Rule 20.11
`Rule 20.12`	필수	# 또는 ## 연산자의 피연산자로 사용되면서 추가 매크로 치환 대상인 매개변수는 이 연산자의 피연산자로만 사용해야 합니다.	Rule 20.12
`Rule 20.13`	필수	첫 토큰이 #인 줄은 유효한 전처리 지시문이어야 합니다.	Rule 20.13
`Rule 20.14`	필수	#else, #elif, #endif는 관련 #if, #ifdef, #ifndef 지시문과 같은 파일에 있어야 합니다.	Rule 20.14
`Rule 21.1`	필수	예약 식별자나 예약 매크로 이름에 #define 또는 #undef를 사용하면 안 됩니다.	Rule 21.1
`Rule 21.2`	필수	예약 식별자나 매크로 이름을 선언하면 안 됩니다.	Rule 21.2
`Rule 21.3`	필수	<stdlib.h>의 메모리 할당·해제 함수를 사용하면 안 됩니다.	MSC24-C Rule 21.3
`Rule 21.4`	필수	표준 헤더 <setjmp.h>를 사용하면 안 됩니다.	Rule 21.4
`Rule 21.6`	필수	표준 라이브러리 입출력 함수를 사용하면 안 됩니다.	Rule 21.6
`Rule 21.7`	필수	<stdlib.h>의 atof, atoi, atol, atoll 함수를 사용하면 안 됩니다.	Rule 21.7
`Rule 21.9`	필수	<stdlib.h>의 bsearch와 qsort 함수를 사용하면 안 됩니다.	Rule 21.9
`Rule 21.11`	필수	표준 헤더 <tgmath.h>를 사용하면 안 됩니다.	Rule 21.11
`Rule 21.12`	권고	<fenv.h>의 예외 처리 기능을 사용하지 않는 것이 좋습니다.	Rule 21.12
`Rule 21.13`	의무	<ctype.h> 함수에 넘기는 값은 unsigned char로 표현할 수 있거나 EOF 값이어야 합니다.	Rule 21.13
`Rule 21.14`	필수	널 종료 문자열 비교에 표준 라이브러리 memcmp 함수를 사용하면 안 됩니다.	Rule 21.14
`Rule 21.15`	필수	memcpy, memmove, memcmp에 넘기는 포인터는 서로 호환되는 형의 한정 또는 비한정 버전을 가리켜야 합니다.	Rule 21.15
`Rule 21.16`	필수	memcmp의 포인터 인수는 포인터형, 본질적 부호 있음·없음·불리언·열거형 가운데 하나를 가리켜야 합니다.	Rule 21.16
`Rule 21.17`	의무	<string.h> 문자열 처리 함수가 포인터 매개변수가 참조하는 객체 경계 밖에 접근하게 하면 안 됩니다.	Rule 21.17
`Rule 21.18`	의무	<string.h> 함수에 넘기는 size_t 인수는 적절한 값이어야 합니다.	Rule 21.18
`Rule 21.19`	의무	localeconv, getenv, setlocale, strerror가 반환한 포인터는 const 한정형 포인터처럼만 사용해야 합니다.	Rule 21.19
`Rule 21.20`	의무	asctime, ctime, gmtime, localtime, localeconv, getenv, setlocale, strerror가 반환한 포인터는 같은 함수를 다시 호출한 뒤 사용하면 안 됩니다.	Rule 21.20
`Rule 22.1`	필수	표준 라이브러리 함수로 동적으로 얻은 모든 자원을 명시적으로 해제해야 합니다.	Rule 22.1
`Rule 22.2`	의무	표준 라이브러리 함수로 할당한 메모리 블록만 해제해야 합니다.	Rule 22.2
`Rule 22.3`	필수	같은 파일을 서로 다른 스트림에서 동시에 읽기와 쓰기로 열면 안 됩니다.	Rule 22.3
`Rule 22.4`	의무	읽기 전용으로 연 스트림에 쓰려고 하면 안 됩니다.	Rule 22.4
`Rule 22.5`	의무	FILE 객체 포인터를 역참조하면 안 됩니다.	Rule 22.5
`Rule 22.6`	의무	연결된 스트림을 닫은 뒤 FILE 포인터 값을 사용하면 안 됩니다.	Rule 22.6
`Rule 22.7`	필수	EOF 매크로는 EOF를 반환할 수 있는 표준 라이브러리 함수의 변경하지 않은 반환값과만 비교해야 합니다.	Rule 22.7
`Rule 22.8`	필수	errno 설정 함수 호출 전에 errno 값을 0으로 설정해야 합니다.	Rule 22.8
`Rule 22.9`	필수	errno 설정 함수 호출 뒤 errno 값을 0과 비교해 검사해야 합니다.	Rule 22.9
`Rule 22.10`	필수	errno는 마지막 호출 함수가 errno 설정 함수일 때만 검사해야 합니다.	Rule 22.10

추가 규칙

규칙 A.1: 조건부 컴파일

심각도: 필수

헤더 파일의 함수 선언과 구조체 선언 자체를 조건부로 컴파일하면 안 됩니다. 다만 어떤 기능을 끈 상태에서 메모리가 낭비되는 것을 피하려면 구조체 정의 안의 필드는 조건부로 제외할 수 있습니다.

컴파일 시점 옵션에 따라 선언을 헤더에서 없애면 해당 선언의 문서가 생성되지 않을 수 있습니다. 선언이 사라지면 선택한 옵션에 따라 코드 경로를 바꿀 때 전처리 조건 대신 if (IS_ENABLED(CONFIG_FOO)) {}를 사용하는 방법도 막힙니다.

규칙 A.2: 포용적 언어

심각도: 필수

아래에 든 공격적 용어의 새로운 사용을 도입하면 안 됩니다. 이 규칙은 소스 코드, 주석, 문서, 브랜치 이름 등을 포함합니다. 대체 용어는 영역이나 하위 시스템에 따라 다를 수 있지만 가능하면 갱신된 업계 표준을 따라야 합니다.

기존 구현을 유지하거나 Zephyr Project 외부 기관이 관리하는 업계 표준 규격의 새 구현을 추가할 때는 예외가 허용됩니다.

업계 표준 규격이 갱신되거나 관리 기관이 새 용어를 공개하면 기존 사용도 가능한 한 빨리 바꾸는 것을 권장합니다. 적용할 규격이 없다면 즉시 변경하는 것이 좋습니다.

피해야 할 용어	권장 대체어
`{master,leader} / slave`	`{primary,main} / {secondary,replica}` `{initiator,requester} / {target,responder}` `{controller,host} / {device,worker,proxy,target}` `director / performer` `central / peripheral`
`blacklist / whitelist`	`denylist / allowlist` `blocklist / allowlist` `rejectlist / acceptlist`
`grandfather policy`	`legacy`
`sanity`	`coherence` `confidence`

공격적 용어는 포용적인 공동체 환경을 만들지 못하므로 Zephyr Project 행동 강령을 위반합니다. 이 규칙은 Linux의 유사 규칙에서 영감을 받았습니다.

관련 GitHub issue와 Pull Request에는 Inclusive Language label이 붙습니다.

영역	선정한 대체어	상태·근거
Bluetooth	Bluetooth Appropriate Language Mapping Tables 참조	Bluetooth 규격 표를 따릅니다.
CAN	CAN in Automation 권고 참조	규격 문서 갱신 용어를 따릅니다.
eSPI	`master / slave` → `controller / target`	eSPI Specification 참조
gPTP	`master / slave` → 미정	공식 용어 확정 대기
I2C	`master / slave` → 미정	NXP는 `controller / target`을 선정했지만 공개 발표 또는 갱신 규격을 기다립니다. Zephyr issue 27033 참조.
I2S·SMP/AMP	`master / slave` → 미정	공식 용어 확정 대기
SPI	`master / slave` → `controller / peripheral` `MOSI / MISO / SS` → `SDO / SDI / CS`	Open Source Hardware Association 결의 참조
Twister	`platform_whitelist` → `platform_allow` `sanitycheck` → `twister`	도구와 속성 이름 갱신

규칙 A.3: 매크로 이름 충돌

심각도: 필수

MIN, MAX, ARRAY_SIZE처럼 널리 쓰이는 매크로 이름은 다른 구현과의 이름 충돌을 피한다는 이유로 수정하거나 보호하면 안 됩니다. Zephyr 전용 접두사를 붙이거나 #undef로 재정의하거나 #ifndef로 조건부 제외해서는 안 됩니다. Module에서 온 기존 정의와 충돌하면 이상적으로는 upstream에서, 아니면 Zephyr fork의 변경으로 module code 자체를 수정해야 합니다.

이 규칙은 매크로가 언제 도입됐고 현재 tree에서 어떤 이름을 쓰는지와 무관하게 Zephyr 전체에 적용됩니다. 널리 알려진 여러 open-source project에서 공통으로 쓰는 이름이라면 Zephyr 구현도 그 이름을 사용해야 합니다. '널리 쓰인다'는 판단에는 주관적인 부분이 있지만 최종 목표는 사용자에게 익숙한 매크로를 제공하는 것입니다.

Module끼리 이름이 충돌할 때도 같은 원칙을 적용합니다. 포함하기 전에 두 module을 수정해 충돌하는 이름에 각 module 전용 버전을 사용해야 합니다.

Zephyr는 독립 프로젝트인 module을 추가 기능과 의존성으로 포함하므로 module이나 Zephyr 자체의 매크로 이름이 충돌할 수 있습니다. 이 문맥에서 중심 프로젝트인 Zephyr가 namespace 없는 일반 이름을 구현하고, 각 module의 Zephyr fork를 patch해 충돌을 피할 수 있습니다.

규칙 A.4: Zephyr kernel의 C 표준 라이브러리 사용 제한

심각도: 필수

Zephyr kernel에서 C 표준 라이브러리 함수와 매크로는 ISO/IEC 9899:2011(C11) 및 명시된 확장 가운데 아래 목록으로 제한합니다.

함수·매크로	근거 표준
`abort()`	ISO/IEC 9899:2011
`abs()`	ISO/IEC 9899:2011
`aligned_alloc()`	ISO/IEC 9899:2011
`assert()`	ISO/IEC 9899:2011
`atoi()`	ISO/IEC 9899:2011
`bsearch()`	ISO/IEC 9899:2011
`calloc()`	ISO/IEC 9899:2011
`exit()`	ISO/IEC 9899:2011
`fprintf()`	ISO/IEC 9899:2011
`fputc()`	ISO/IEC 9899:2011
`fputs()`	ISO/IEC 9899:2011
`free()`	ISO/IEC 9899:2011
`fwrite()`	ISO/IEC 9899:2011
`gmtime()`	ISO/IEC 9899:2011
`isalnum()`	ISO/IEC 9899:2011
`isalpha()`	ISO/IEC 9899:2011
`iscntrl()`	ISO/IEC 9899:2011
`isdigit()`	ISO/IEC 9899:2011
`isgraph()`	ISO/IEC 9899:2011
`isprint()`	ISO/IEC 9899:2011
`isspace()`	ISO/IEC 9899:2011
`isupper()`	ISO/IEC 9899:2011
`isxdigit()`	ISO/IEC 9899:2011
`labs()`	ISO/IEC 9899:2011
`llabs()`	ISO/IEC 9899:2011
`malloc()`	ISO/IEC 9899:2011
`memchr()`	ISO/IEC 9899:2011
`memcmp()`	ISO/IEC 9899:2011
`memcpy()`	ISO/IEC 9899:2011
`memmove()`	ISO/IEC 9899:2011
`memset()`	ISO/IEC 9899:2011
`perror()`	ISO/IEC 9899:2011
`printf()`	ISO/IEC 9899:2011
`putc()`	ISO/IEC 9899:2011
`putchar()`	ISO/IEC 9899:2011
`puts()`	ISO/IEC 9899:2011
`qsort()`	ISO/IEC 9899:2011
`rand()`	ISO/IEC 9899:2011
`realloc()`	ISO/IEC 9899:2011
`snprintf()`	ISO/IEC 9899:2011
`sprintf()`	ISO/IEC 9899:2011
`sqrt()`	ISO/IEC 9899:2011
`sqrtf()`	ISO/IEC 9899:2011
`srand()`	ISO/IEC 9899:2011
`strcat()`	ISO/IEC 9899:2011
`strchr()`	ISO/IEC 9899:2011
`strcmp()`	ISO/IEC 9899:2011
`strcpy()`	ISO/IEC 9899:2011
`strcspn()`	ISO/IEC 9899:2011
`strerror()`	ISO/IEC 9899:2011
`strlen()`	ISO/IEC 9899:2011
`strncat()`	ISO/IEC 9899:2011
`strncmp()`	ISO/IEC 9899:2011
`strncpy()`	ISO/IEC 9899:2011
`strnlen()`	POSIX.1-2008
`strrchr()`	ISO/IEC 9899:2011
`strspn()`	ISO/IEC 9899:2011
`strstr()`	ISO/IEC 9899:2011
`strtol()`	ISO/IEC 9899:2011
`strtoll()`	ISO/IEC 9899:2011
`strtoul()`	ISO/IEC 9899:2011
`strtoull()`	ISO/IEC 9899:2011
`time()`	ISO/IEC 9899:2011
`tolower()`	ISO/IEC 9899:2011
`toupper()`	ISO/IEC 9899:2011
`vfprintf()`	ISO/IEC 9899:2011
`vprintf()`	ISO/IEC 9899:2011
`vsnprintf()`	ISO/IEC 9899:2011
`vsprintf()`	ISO/IEC 9899:2011

위 함수는 모두 minimal libc가 구현해야 합니다. 그래야 Zephyr kernel을 minimal libc로 build할 수 있습니다.

목록에서 ISO/IEC 9899:2011에 속하지 않는 함수는 여러 C 표준 라이브러리에서 쓸 수 있도록 common libc도 구현해야 합니다.

이 요구 사항을 만족하고 정당한 이유가 있다면 Zephyr kernel에 새 C 표준 라이브러리 함수를 도입할 수 있습니다. 목록에 있다는 사실은 무조건 사용해도 된다는 뜻이 아니며 안전하고 보안성 있는 coding 관행을 따라야 합니다.

이 규칙에서 Zephyr kernel은 다음 component로 구성됩니다.

kernel의 Kernel
lib/os의 OS Library
arch의 Architecture Port
subsys/logging의 Logging Subsystem

Zephyr Project가 유지보수하는 제한된 C 표준 라이브러리인 minimal libc로 kernel과 핵심 OS service를 자체적으로 시험·검증할 수 있어야 합니다. 따라서 kernel의 libc 사용을 minimal libc가 제공하는 함수와 매크로로 제한해야 합니다.

규칙 A.5: Zephyr codebase의 C 표준 라이브러리 사용 제한

심각도: 필수

이 규칙에서 예외로 인정한 경우를 빼면 Zephyr codebase의 C 표준 라이브러리 함수와 매크로 사용은 ISO/IEC 9899:2011(C11)의 함수로 제한하며 Annex K 'Bounds-checking interfaces'는 제외합니다.

Zephyr codebase는 앞의 A.4 규칙에서 정의한 Zephyr kernel을 제외하고 main Zephyr repository에 commit된 모든 embedded source code file을 뜻합니다. Embedded source code는 embedded target에서 실행할 code이므로 host tooling과 native test target 전용 code는 제외합니다.

다음 비표준 함수와 매크로는 이 규칙의 예외로 Zephyr codebase에서 사용할 수 있습니다.

함수·매크로	근거 표준
`gmtime_r()`	POSIX.1-2001
`strnlen()`	POSIX.1-2008
`strtok_r()`	POSIX.1-2001

위 비표준 함수와 매크로는 해당 함수를 구현하지 않는 C 표준 라이브러리를 사용할 때도 제공할 수 있도록 common libc가 구현해야 합니다.

요구 사항을 만족하고 정당한 이유가 있다면 일반적인 C library의 새 비표준 함수를 목록에 추가할 수 있습니다. 기능적으로 같은 표준 함수가 있으면 표준 함수를 사용해야 합니다.

Newlib과 Picolibc 같은 일부 C 표준 라이브러리는 POSIX나 Linux처럼 ISO C를 확장하는 표준 또는 사실상 표준의 함수와 매크로를 추가로 제공합니다. ISO/IEC 9899:2011은 compiler toolchain에 이런 비표준 함수 지원을 요구하지 않으므로 사용하면 자체 C library를 제공하는 third-party toolchain과 호환성 문제가 생길 수 있습니다.

원문 외부 참조

본문의 정책 근거, 규격, issue와 API 정의로 이어지는 원문 외부 링크입니다.

Source

출처

영어 원문에는 문단, 문서 지시문, 표, 코드, 코드 심벌, 경로를 그대로 보존했습니다.

Coding Guidelines

2.7.0 LTS2 · 준비 중

요약·해설

접을 수 있는 영어 원문 전체

한국어 전문 번역

Coding Guidelines

단계별 적용

주요 규칙

추가 규칙

규칙 A.1: 조건부 컴파일

규칙 A.2: 포용적 언어

규칙 A.3: 매크로 이름 충돌

규칙 A.4: Zephyr kernel의 C 표준 라이브러리 사용 제한

규칙 A.5: Zephyr codebase의 C 표준 라이브러리 사용 제한

원문 외부 참조

출처