On Wed, 15 May 2024, Stefano Stabellini wrote: > On Wed, 15 May 2024, Jan Beulich wrote: > > On 15.05.2024 01:15, Stefano Stabellini wrote: > > > Add D4.12 with the same explanation as the rules of the R21 series. > > > D4.12 refers to the standard library memory allocation functions and > > > similar third party libraries with memory allocation functions. It > > > doesn't refer to the in-tree implementation we have in Xen which is > > > subject to MISRA C rules and MISRA C scanning. > > > > > > Signed-off-by: Stefano Stabellini <stefano.stabell...@amd.com> > > > > > > diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst > > > index 80e5e972ad..bc8506add4 100644 > > > --- a/docs/misra/rules.rst > > > +++ b/docs/misra/rules.rst > > > @@ -76,6 +76,11 @@ maintainers if you want to suggest a change. > > > considered libraries from MISRA C point of view as they are > > > imported in source form) > > > > > > + * - `Dir 4.12 > > > <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/D_04_12.c>`_ > > > + - Required > > > + - Dynamic memory allocation shall not be used > > > + - Xen doesn't provide, use, or link against a Standard Library > > > [#xen-stdlib]_ > > > > I'm having trouble connecting this remark with the directive. We do have > > dynamic memory allocation routines, and we use them. It doesn't really > > matter that they don't come from an external library, does it? > > Similarly to the 21.x rules series, it makes a difference if they are > external libraries or code within the project. The rule points out that > the standard library memory allocation functions can lead to undefined > behavior. On the other hand, our own implementation under xen.git is > subject to MISRA C scanning and all the other MISRA C rules. > > The example in the link above, shows a use-after-free error that in our > case it should be caught by other MISRA C rules scanning.
Just to close the loop on this -- I spoke with Roberto about D4.12, and we decided that it is best to leave out this directive for now.
