Re: [XEN PATCH] xen/arm: p2m: refactor 'p2m_get_entry'

[Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>]

On 21/07/23 12:01, Julien Grall wrote:
> Hi Nicola,
>
> I would add "to please ECLAIR" in the commit title.
I would be against this. It's the MISRA assessor that needs
to understand and agree on what has been done to claim MISRA compliance. 
A static analysis tool is just a useful way to help reaching this aim.
> On 21/07/2023 07:49, Nicola Vetrini wrote:
> > This function is refactored to avoid using a
> > local dummy variable that served as a fallback
> > if the parameter 't' is NULL.
> >
> > Storing the address of that variable into 't' caused
> > static analysis tools not to be able to recognize the
> Can you mention which static analysis tools is not happy and the 
> version? This could help us in the future if we decided to revert the 
> patch.
It is not a matter of tool happiness, but of MISRA compliance.
There are several tools (even emblazoned ones) that have lots
of false negatives, also for mandatory guidelines such as Rule 9.1:
the fact that they do not issue messages for possible violations
they cannot exclude is happiness for nobody (especially for those
who have to ensure there are indeed no violations). Two things
that have to be kept well in mind are:

1) Rule 9.1 is undecidable, there will never be a tool that flags all
   and only the violations; tools will false positives, false negatives
   or both. ECLAIR (all versions of it) errs on the safe side.

2) Safety-critical code has to be boring and obviously correct:
   programming virtuosism and safety are in two very different leagues.
   This is why ECLAIR uses the algorithm it uses: typically when it
   issues a caution the code is not obviously correct.

Kind Regards,

--
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)