Re: [XEN PATCH v2 1/3] docs/misra: add documentation skeleton for MISRA C:2012 Dir 4.1

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Thu, 28 Sep 2023, Nicola Vetrini wrote:
> On 28/09/2023 02:55, Stefano Stabellini wrote:
> > On Wed, 27 Sep 2023, Nicola Vetrini wrote:
> > > The aforementioned directive requires the project to supply documentation
> > > on the measures taken towards the minimization of run-time failures.
> 
> > > +
> > > +Documentation for MISRA C:2012 Dir 4.1: mistyped access to function
> > > +___________________________________________________________________
> > > +
> > > +The code never uses function pointers.
> > 
> > You missed my previous comment on this one
> > 
> 
> You're right.
> This is about the usage of a function having a certain signature as having
> another.
> It could happen for instance:
> - with incongruent declarations
> - no prototypes
> - casts on function pointers
> Most of these can be caught by complying with other rules, but I'm not sure if
> they
> fully cover every case, and besides there are still violations on the rules
> tied to this.
> I guess we can say that this is a WIP.

We do want to follow these guidelines and like you wrote they are
covered by other MISRA rules that we have adopted and we are already
scanning for (or planning to) using ECLAIR. I think we should highlight
that, especially we have done a lot of work on incongruent declarations
and missing prototypes.


> > > +
> > > +Documentation for MISRA C:2012 Dir 4.1: invariant violation
> > > +___________________________________________________________
> > > +
> > > +To be written.
> > 
> > Also this one escaped.
> > 
> > Overall, this is much better!
> > 
> 
> I replied on v1, but maybe I missed some further reply:
> It's the violation of a project invariant (e.g., an assert or BUILD_BUG).
> Something along the lines of this could fit in the documentation:
> "The extensive checks in the code ensure that any violation of a
> compile-time invariant will be detected in prior to release builds, and
> failure
> of run-time invariant is also extensively tested."

We can also add the number of invariants is drastically reduced in
release builds.