On 2025-04-28 08:15, Jan Beulich wrote:
On 25.04.2025 17:53, Nicola Vetrini wrote:
On 2025-04-25 10:07, Jan Beulich wrote:
On 24.04.2025 23:45, Stefano Stabellini wrote:
On Thu, 24 Apr 2025, Jan Beulich wrote:
On 23.04.2025 19:54, victorm.l...@amd.com wrote:
From: Nicola Vetrini <nicola.vetr...@bugseng.com>
MISRA C Rules 21.1 ("#define and #undef shall not be used on a
reserved identifier or reserved macro name") and R21.2 ("A
reserved
identifier or reserved macro name shall not be declared")
violations
are not problematic for Xen, as it does not use the C or POSIX
libraries.
Xen uses -fno-builtin and -nostdinc to ensure this, but there are
still
__builtin_* functions from the compiler that are available so
a deviation is formulated for all identifiers not starting with
"__builtin_".
The missing text of a deviation for Rule 21.2 is added to
docs/misra/deviations.rst.
To avoid regressions, tag both rules as clean and add them to the
monitored set.
Signed-off-by: Nicola Vetrini <nicola.vetr...@bugseng.com>
Signed-off-by: Federico Serafini <federico.seraf...@bugseng.com>
Signed-off-by: Victor Lira <victorm.l...@amd.com>
While the rule is in the library section, ...
--- a/docs/misra/deviations.rst
+++ b/docs/misra/deviations.rst
@@ -587,7 +587,31 @@ Deviations related to MISRA C:2012 Rules:
construct is deviated only in Translation Units that
present
a violation
of the Rule due to uses of this macro.
- Tagged as `deliberate` for ECLAIR.
-
+
+ * - R21.1
+ - Rule 21.1 reports identifiers reserved for the C and POSIX
standard
+ libraries. Xen does not use such libraries and all
translation units
+ are compiled with option '-nostdinc', therefore there is
no
reason to
+ avoid to use `#define` or `#undef` on such identifiers
except for those
+ beginning with `__builtin_` for which compilers may
perform
(wrong)
+ optimizations.
+ - Tagged as `safe` for ECLAIR.
... I'd like to ask that it be explicitly clarified here that it's
solely
the library (and not e.g. the compiler itself) that are of concern
here.
The language can be clarified:
- Rule 21.1 reports identifiers reserved for the C and POSIX
standard
libraries. Xen does not use such libraries and all translation
units
are compiled with option '-nostdinc', therefore there is no reason
to
avoid to use `#define` or `#undef` on C and POSIX standard
libraries
identifiers except for those beginning with `__builtin_` for which
compilers may perform (wrong) optimizations.
Which makes it more apparent that there is a gap: What about e.g.
__x86_64__?
That falls within what the rules cover, is not a C or POSIX standard
library
identifier, yet very clearly must not be fiddled with. Whereas the
text
above deviates it.
that is true, even if unlikely: one approach could be to avoid
deviating
predefined macros for all CUs as -nostdinc and -fno-builtins should
take
care of the rest; this kind of deviation is not currently possible in
ECLAIR, but it might be in the future.
Is this perhaps because by "all pre-defined macros" you really mean
_just_
those, and not the entire reserved (for that purpose) sub-namespace?
Imo
we should not go by what a particular compiler may pre-define (we may
even
overlook something if we did it this way).
Jan
I think there is a slight misalignment here: maybe I'm interpreting your
answer incorrectly. Let me try to restate the proposal: the following
identifiers are not allowed to be #define'd or #undef'd:
- __builtin_*
- for each CU, all macro identifiers already defined upon preprocessing
that CU by the compiler invocation for that CU. This set of identifiers
is always a subset of all the reserved identifiers, but is also
dependent on the compiler invocation that is used for that CU, (e.g.
__x86_64__ for an Arm target is usually safe to define, as it's
typically not a predefined macro introduced by the compiler for that
invocation, while (re)defining __STDC_VERSION__ or __SIZEOF_INT__ will
be a violation in any command line I can think of). Note that this is
not a static set, but is based on what is determined to be predefined at
the moment of the analysis, so it is not tied to what a particular
compiler pre-defines.
I think this could be
accomplished also via some gcc trickery on each CU, though I'm not
sure
how valued that is for Xen.
--
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253
