On 09.06.2023 19:45, Stefano Stabellini wrote: > @@ -133,6 +146,13 @@ existing codebase are work-in-progress. > headers (xen/include/public/) are allowed to retain longer > identifiers for backward compatibility. > > + * - `Rule 6.1 > <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_06_01.c>`_ > + - Required > + - Bit-fields shall only be declared with an appropriate type > + - In addition to the C99 types, we also consider appropriate types: > + unsigned char, unsigned short, unsigned long, unsigned long long, > + enum.
What about their signed equivalents? I'm surprised that I found only very few uses (in Arm insn decoding afaict), but they generally have a purpose. Are the uses we have (and new ones which may appear) intended to become deviations? > @@ -143,6 +163,12 @@ existing codebase are work-in-progress. > - Octal constants shall not be used > - > > + * - `Rule 7.2 > <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_07_02.c>`_ > + - Required > + - A "u" or "U" suffix shall be applied to all integer constants > + that are represented in an unsigned type > + - I continue to consider "represented in" problematic here without further qualification. > @@ -314,6 +340,11 @@ existing codebase are work-in-progress. > used following a subsequent call to the same function > - > > + * - Rule 21.21 > + - Required > + - The Standard Library function system of <stdlib.h> shall not be used > + - Still no "inapplicable" note (whichever way it would be worded to also please Roberto)? Jan
