Re: [XEN PATCH 09/13] xen/common: address violations of MISRA C:2012 Directive 4.10

[Simone Ballarin <simone.ballarin@xxxxxxxxxxx>]

On 06/09/23 00:18, Stefano Stabellini wrote:
> On Thu, 31 Aug 2023, Simone Ballarin wrote:
> > On 31/08/23 15:05, Jan Beulich wrote:
> > > On 31.08.2023 14:54, Simone Ballarin wrote:
> > > > On 31/08/23 13:10, Jan Beulich wrote:
> > > > > On 31.08.2023 12:08, Simone Ballarin wrote:
> > > > > > The danger of multi-inclusion also exists for .c files, why do you
> > > > > > want
> > > > > > to avoid guards for them?
> > > > > Counter question: Why only add guards to some of them? (My personal
> > > > > answer is "Because it's extra clutter.")
> > > > It's not "some of them", it's exactly the ones used in an #include
> > > > directive, so I'm not getting your objection.
> > > My point is that by adding guards only for files we presently use in some
> > > #include directive, we set us up for introducing new violations as soon
> > > as another .c file becomes the subject of an #include.The more that it
> > > is unusual to add guards in .c files, i.e. it is to be expected that
> > > people wouldn't think about this extra Misra requirement.
> > >
> > > Jan
> > I can agree to partially adopt the directive: I will add a deviation for C
> > files in rules.txt.
> Sorry for the late reply as I was OOO. Please hold on before adding a
> deviation for C files.
>
> In general, I think including .c files is not common behavior, and
> should be restricted to special cases. We could say that exactly because
> they are special, they follow different rules so we can skip the guards.
> Or we could say that they are still at risk of double-inclusion, hence
> we should be consistent and protect them too. I think we should discuss
> the topic during the next MISRA C meeting.
Ok, I will drop changes in C files without adding the deviation.

--
Simone Ballarin, M.Sc.

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