On 2026-02-25 13:14, Andrew Cooper wrote:
On 23/02/2026 7:26 am, Roberto Bagnara wrote:
On 20/02/26 22:46, Andrew Cooper wrote:
Eclair complains of a side effect in a sizeof() expression (R13.6).
I disagree with comments of the form "Eclair complains"
We use the same phrasing with other tools too, but I can change it to
"reports" which I suppose is a more neutral term.
Note that in recent versions of MISRA C that rule is no longer
mandatory. More generally, note also that, IMHO, switching to
a more modern version of MISRA C would simplify compliance.
Ok. Making things simpler for compliance sounds like a good thing.
What would this entail?
Presumably we've got to adapt to all changes in this newer revision of
MISRA C.
~Andrew
Most likely new violations on new non-clean guidelines, generally rules
for features that were standardized in C11/C18 and were previously
widely available extensions (e.g. _Noreturn, _Alignof, threads, ...),
alongside some minor changes in existing ones, such as the
classification change mentioned by Roberto. The exact impact depends on
the target MISRA revision, however. Making an experiment should be only
a matter of s/MC3A2/MC4/ (or whichever MISRA revision is chosen: MC4 in
ECLAIR refers to the latest published MISRA revision, that is, MISRA
C:2025. Perhaps also a few regressions (as in newly introduced
violations) on clean ones, but I do not expect the results to be
radically different.
Side note here: are the efforts to make Xen compile with -stc=c11/gnu11
still ongoing? I say this because any MISRA revision other than the one
currently used by Xen by default is based on C11, as it introduces
guidelines for C11/C18 features. Not that this would matter a whole lot
for Xen, but it is something to consider in the broader picture.
--
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253
