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
