Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
---
Changes in v3:
- better clarify what is allowed and not allowed with examples
---
 docs/misra/rules.rst | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst
index 1e134ccebc..5766b2286d 100644
--- a/docs/misra/rules.rst
+++ b/docs/misra/rules.rst
@@ -181,6 +181,21 @@ maintainers if you want to suggest a change.
        headers (xen/include/public/) are allowed to retain longer
        identifiers for backward compatibility.
 
+   * - `Rule 5.5 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_05_05.c>`_
+     - Required
+     - Identifiers shall be distinct from macro names
+     - Macros expanding to their own name are allowed, e.g.::
+
+           #define x x
+
+       Clashes between names of function-like macros and identifiers of
+       non-callable entities are allowed. Callable entities having an
+       identifier that is the same of the name of a
+       function-like macro are not allowed. Example (not allowed)::
+
+           #define f(x, y) f(x, y);
+           void f(int x, int y);
+
    * - `Rule 5.6 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_05_06.c>`_
      - Required
      - A typedef name shall be a unique identifier
-- 
2.25.1

Hi Stefano,

> On 15 Mar 2024, at 01:35, Stefano Stabellini <sstabellini@kernel.org> wrote:
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>

With the semicolon comment from Jan addressed:

Acked-by: Bertrand Marquis <bertrand.marquis@arm.com>

Cheers
Bertrand

On 15.03.2024 01:35, Stefano Stabellini wrote:
> --- a/docs/misra/rules.rst
> +++ b/docs/misra/rules.rst
> @@ -181,6 +181,21 @@ maintainers if you want to suggest a change.
>         headers (xen/include/public/) are allowed to retain longer
>         identifiers for backward compatibility.
>  
> +   * - `Rule 5.5 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_05_05.c>`_
> +     - Required
> +     - Identifiers shall be distinct from macro names
> +     - Macros expanding to their own name are allowed, e.g.::
> +
> +           #define x x
> +
> +       Clashes between names of function-like macros and identifiers of
> +       non-callable entities are allowed. Callable entities having an
> +       identifier that is the same of the name of a
> +       function-like macro are not allowed. Example (not allowed)::
> +
> +           #define f(x, y) f(x, y);

The semicolon here wants dropping, just to not give questionable constructs
as examples.

> +           void f(int x, int y);

With this not allowed and there (iirc) being examples of such in the code,
I'll be curious how it is meant to deal with them.

Jan

On Fri, 15 Mar 2024, Jan Beulich wrote:
> On 15.03.2024 01:35, Stefano Stabellini wrote:
> > --- a/docs/misra/rules.rst
> > +++ b/docs/misra/rules.rst
> > @@ -181,6 +181,21 @@ maintainers if you want to suggest a change.
> >         headers (xen/include/public/) are allowed to retain longer
> >         identifiers for backward compatibility.
> >  
> > +   * - `Rule 5.5 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_05_05.c>`_
> > +     - Required
> > +     - Identifiers shall be distinct from macro names
> > +     - Macros expanding to their own name are allowed, e.g.::
> > +
> > +           #define x x
> > +
> > +       Clashes between names of function-like macros and identifiers of
> > +       non-callable entities are allowed. Callable entities having an
> > +       identifier that is the same of the name of a
> > +       function-like macro are not allowed. Example (not allowed)::
> > +
> > +           #define f(x, y) f(x, y);
> 
> The semicolon here wants dropping, just to not give questionable constructs
> as examples.

Good point


> > +           void f(int x, int y);
> 
> With this not allowed and there (iirc) being examples of such in the code,
> I'll be curious how it is meant to deal with them.

I don't know how many violations we have, and if there is a general
pattern we could apply to address them. As usual we'll have a choice
between changing the code or adding a deviation.