Re: [PATCH] docs/misra: add D4.12

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

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.stabellini@xxxxxxx>
> > > 
> > > 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.