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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Thu, 26 Oct 2023, Jan Beulich wrote:
> On 26.10.2023 03:16, Stefano Stabellini wrote:
> > On Wed, 25 Oct 2023, Jan Beulich wrote:
> >> On 25.10.2023 03:15, Stefano Stabellini wrote:
> >>> And if we can find a clear general comment about the usage of leading
> >>> underscores in Xen I am happy to add it too (e.g. header guards), but
> >>> from MISRA point of view the above is sufficient.
> >>
> >> But what we need isn't a description of the status quo, but one of
> >> what state we want to (slowly) move to. The status quo anyway is
> >> "no pattern, as in the past hardly anyone cared".
> > 
> > I guess you are suggesting something more like the following, but please
> > feel free to suggest your favorite wording (it might be easier for me to
> > understand what you mean if you provide a short example).
> > 
> > ---
> > All identifiers starting with an underscore are reserved and should not
> > be used.
> 
> Again, no. Identifiers starting with an underscore followed by another
> underscore or an upper-case letter are reserved. Other identifiers are
> dedicated for a particular purpose, and are fine to use for (at least)
> that purpose.
> 
> > Today Xen uses many, such as header guards and bitwise
> > manipulation functions. Upon analysis it turns out Xen identifiers do
> > not clash with the identifiers used by modern GCC, but that is not a
> > guarantee that there won't be a naming clash in the future or with
> > another compiler. For these reasons we discourage the introduction of
> > new reserved identifiers in Xen, and we see it as positive the reduction
> > of reserved identifiers. At the same time, certain identifiers starting
> > with an underscore are also commonly used in Linux (e.g. __set_bit) and
> > we don't think it would be an improvement to rename them.
> 
> Everything else reads okay-ish to me.

OK, here is the new version

Identifiers starting with an underscore followed by another underscore
or an upper-case letter are reserved. Today Xen uses many, such as
header guards and bitwise manipulation functions. Upon analysis it turns
out Xen identifiers do not clash with the identifiers used by modern
GCC, but that is not a guarantee that there won't be a naming clash in
the future or with another compiler.  For these reasons we discourage
the introduction of new reserved identifiers in Xen, and we see it as
positive the reduction of reserved identifiers. At the same time,
certain identifiers starting with an underscore are also commonly used
in Linux (e.g. __set_bit) and we don't think it would be an improvement
to rename them.