Re: [PATCH 1/2] automation/eclair_analysis: deviate MISRA C Rule 21.2

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Fri, 21 Jun 2024, Jan Beulich wrote:
> On 21.06.2024 03:02, Stefano Stabellini wrote:
> > On Thu, 20 Jun 2024, Jan Beulich wrote:
> >> On 19.06.2024 19:09, Alessandro Zucchelli wrote:
> >>> Rule 21.2 reports identifiers reserved for the C and POSIX standard
> >>> libraries: all xen's translation units are compiled with option
> >>> -nostdinc, this guarantees that these libraries are not used, therefore
> >>> a justification is provided for allowing uses of such identifiers in
> >>> the project.
> >>> Builtins starting with "__builtin_" still remain available.
> >>>
> >>> No functional change.
> >>>
> >>> Signed-off-by: Alessandro Zucchelli <alessandro.zucchelli@xxxxxxxxxxx>
> >>> ---
> >>>  automation/eclair_analysis/ECLAIR/deviations.ecl | 11 +++++++++++
> >>>  1 file changed, 11 insertions(+)
> >>>
> >>> diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl 
> >>> b/automation/eclair_analysis/ECLAIR/deviations.ecl
> >>> index 447c1e6661..9fa9a7f01c 100644
> >>> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
> >>> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
> >>> @@ -487,6 +487,17 @@ leads to a violation of the Rule are deviated."
> >>>  # Series 21.
> >>>  #
> >>>  
> >>> +-doc_begin="Rules 21.1 and 21.2 report identifiers reserved for the C 
> >>> and POSIX
> >>> +standard libraries: if these libraries are not used there is no reason 
> >>> to avoid such
> >>> +identifiers. All xen's translation units are compiled with option 
> >>> -nostdinc,
> >>> +this guarantees that these libraries are not used. Some compilers could 
> >>> perform
> >>> +optimization using built-in functions: this risk is partially addressed 
> >>> by
> >>> +using the compilation option -fno-builtin. Builtins starting with 
> >>> \"__builtin_\"
> >>> +still remain available."
> >>
> >> While the sub-section "Reserved Identifiers" is part of Section 7,
> >> "Library", close coordination is needed between the library and the
> >> compiler, which only together form an "implementation". Therefore any
> >> use of identifiers beginning with two underscores or beginning with an
> >> underscore and an upper case letter is at risk of colliding not only
> >> with a particular library implementation (which we don't use), but
> >> also of such with a particular compiler implementation (which we cannot
> >> avoid to use). How can we permit use of such potentially problematic
> >> identifiers?
> > 
> > Alternative question: is there a way we can check if there is clash of
> > some sort between a compiler implementation of something and a MACRO or
> > identifier we have in Xen? An error or a warning from the compiler for
> > instance? That could be an easy way to prove we are safe.
> 
> Well. I think it is the default for the compiler to warn when re-#define-
> ing a previously #define-d (by the compiler or by us) symbol, so on that
> side we ought to be safe at any given point in time,

OK, that's good. It seems to me that this explanation should be part of
the deviation text.


> yet we're still latently unsafe (as to compilers introducing new
> pre-defines).

Sure, but we don't need to be safe in relation to future compiler. Right
now, we are targeting gcc-12.1.0 as written in
docs/misra/C-language-toolchain.rst. When we decide to enable a new
compiler in Xen we can fix/change any specific define as needed. Also
note the large amount of things written in C-language-toolchain.rst that
need to be checked and verified for a new compiler to make sure we can
actually use it safely (we make many assumptions).


> For built-in declarations, though, there's nothing I'm aware of that
> would indicate collisions.

For builtins, Alessandro was suggesting -fno-builtin. One question to
Alessandro is why would -fno-builtin only "partially" address the
problem.

Another question for Jan and also Alessandro: given that builtins
starting with __builtin_ remain available, any drawbacks in using
-fno-builtin in a Xen build?



> > Also, can we use the fact that the compiler we use is the same compiler
> > used to compile Linux, and Linux makes extensive use of identifiers and
> > macros starting with underscores as one of the reason for being safe
> > from clashes?
> 
> I think we could, but I don't think we should.