Re: [PATCH] misra: add R14.4 R21.1 R21.2

[Jan Beulich <jbeulich@xxxxxxxx>]

On 24.10.2023 01:31, Stefano Stabellini wrote:> --- a/docs/misra/rules.rst
> +++ b/docs/misra/rules.rst
> @@ -422,6 +422,13 @@ maintainers if you want to suggest a change.
>  
>         while(0) and while(1) and alike are allowed.
>  
> +   * - `Rule 14.4 
> <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_14_04.c>`_
> +     - Required
> +     - The controlling expression of an if statement and the controlling
> +       expression of an iteration-statement shall have essentially
> +       Boolean type
> +     - Implicit conversions to boolean are allowed

What, if anything, remains of this rule with this exception?

> @@ -479,6 +486,24 @@ maintainers if you want to suggest a change.
>         they are related
>       -
>  
> +   * - `Rule 21.1 
> <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_21_01.c>`_
> +     - Required
> +     - #define and #undef shall not be used on a reserved identifier or
> +       reserved macro name
> +     - No identifiers should start with _BUILTIN to avoid clashes with

DYM "__builtin_"? Also gcc introduces far more than just __builtin_...()
into the name space.

> +       GCC reserved identifiers. In general, all identifiers starting with
> +       an underscore are reserved, and are best avoided.

This isn't precise enough. A leading underscore followed by a lower-case
letter or a number is okay to use for file-scope symbols. Imo we should
not aim at removing such uses, but rather encourage more use.

In this context, re-reading some of the C99 spec, I have to realize that
my commenting on underscore-prefixed macro parameters (but not underscore-
prefixed locals in macros) was based on ambiguous information in the spec.
I will try to remember to not comment on such anymore going forward.

> However, Xen
> +       makes extensive usage of leading underscores in header guards,
> +       bitwise manipulation functions, and a few other places. They are
> +       considered safe as checks have been done against the list of
> +       GCC's reserved identifiers. They don't need to be replaced.

This leaves quite vague what wants and what does not want replacing, nor
what might be okay to introduce subsequently despite violation this rule.

Jan