On 16.04.2024 21:27, Stefano Stabellini wrote: > Also add two specific project-wide deviations for R21.6 and R21.15. > > Signed-off-by: Stefano Stabellini <stefano.stabell...@amd.com> > > diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst > index 32b02905d1..9123c8edb5 100644 > --- a/docs/misra/deviations.rst > +++ b/docs/misra/deviations.rst > @@ -387,6 +387,22 @@ Deviations related to MISRA C:2012 Rules: > of the Rule due to uses of this macro. > - Tagged as `deliberate` for ECLAIR. > > + * - R21.6 > + - The use of snprintf() and vsnprintf() is justifiable as, despite > + the fact that such functions have the same names of the > + corresponding standard library functions, each configuration of > + Xen has a unique implementation for them; the code implementing > + such functions is subject to the analysis, so that any undefined > + or unspecified behavior associated to them falls under the > + responsibility of other MISRA guidelines
Checking the Misra spec, I'm actually surprised a deviation is needed. The rule's rationale talks about streams and file I/O only. Why would the string formatting functions be covered then at all? They also don't have, afaik, any undefined or implementation defined behavior. > + - Tagged as `safe` for ECLAIR. > + > + * - R21.15 > + - The use of void* arguments is justifiable as the rationale for > + the rule is to indicate possible mistakes, and void* is > + frequently used in Xen to represent virtual memory addresses But that doesn't rule out mistakes. Are there actually examples in the code base? Additionally I wonder (a) whether the rule actually needs an exception and thus (b) whether the deviation isn't instead for 21.16. As to (a) I understand the rule is worded slightly differently than what would strictly be needed to permit void*, but the general rule in C is that void* is compatible with all other pointers (suitably qualified as needed, of course) anyway. Jan
