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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 06.09.2023 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.
>>
>> 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.

Just one further remark right here: While including a header file a 2nd
time stands a fair chance of working (i.e. the compiler not spitting out
errors), that would be very unusual for a .c file: Every function or
data item it defines would (in the common case) be already defined.

Jan