Re: [XEN PATCH 01/13] misra: add deviation for headers that explicitly avoid guards

[Simone Ballarin <simone.ballarin@xxxxxxxxxxx>]

On 29/08/23 00:32, Stefano Stabellini wrote:
> On Mon, 28 Aug 2023, Stefano Stabellini wrote:
> > On Mon, 28 Aug 2023, Simone Ballarin wrote:
> > > Some headers, under specific circumstances (documented in a comment at
> > > the beginning of the file), explicitly avoid inclusion guards: the caller
> > > is responsible for including them correctly.
> > >
> > > These files are not supposed to comply with Directive 4.10:
> > > "Precautions shall be taken in order to prevent the contents of a header
> > > file being included more than once"
> > >
> > > This patch adds a deviation for all headers that contain the following
> > > in a comment text:
> > > "In this case, no inclusion guards apply and the caller is responsible"
> > >
> > > Signed-off-by: Simone Ballarin <simone.ballarin@xxxxxxxxxxx>
> > Acked-by: Stefano Stabellini <sstabellini@xxxxxxxxxx>
> Actually one question
>
>
> > > ---
> > >   automation/eclair_analysis/ECLAIR/deviations.ecl | 4 ++++
> > >   docs/misra/rules.rst                             | 3 ++-
> > >   2 files changed, 6 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl 
> > > b/automation/eclair_analysis/ECLAIR/deviations.ecl
> > > index d8170106b4..5f068377fa 100644
> > > --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
> > > +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
> > > @@ -91,6 +91,10 @@ conform to the directive."
> > >   -config=MC3R1.D4.10,reports+={safe, "first_area(text(^/\\* Generated file, do not 
> > > edit! \\*/$, begin-3))"}
> > >   -doc_end
> > >   
> > > +-doc_begin="Some headers, under specific circumstances, explicitly avoid inclusion guards."
> > > +-config=MC3R1.D4.10,reports+={safe, "first_area(text(^ \\* In this case, no 
> > > inclusion guards apply and the caller is responsible.*\\*/$, begin-1))"}
> > > +-doc_end
> Is this supposed to match with any files starting with "In this case,
> no inclusion..." ?
>
> We should use the format introduced by safe.json instead
I agree, I will do it in the next submission.

--
Simone Ballarin, M.Sc.

Field Application Engineer, BUGSENG (https://bugseng.com)