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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

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.