On 31/08/23 13:10, Jan Beulich wrote:
On 31.08.2023 12:08, Simone Ballarin wrote:
On 29/08/23 08:50, Jan Beulich wrote:
On 28.08.2023 15:20, Simone Ballarin wrote:
Add inclusion guards to address violations of
MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order
to prevent the contents of a header file being included more than
once").
Also C files, if included somewhere, need to comply with the guideline.
Mechanical change.
Signed-off-by: Simone Ballarin <simone.balla...@bugseng.com>
---
xen/common/compat/grant_table.c | 7 +++++++
xen/common/coverage/gcc_4_7.c | 5 +++++
xen/common/decompress.h | 5 +++++
xen/common/event_channel.h | 5 +++++
xen/common/multicall.c | 5 +++++
5 files changed, 27 insertions(+)
As already said in reply to another patch, imo .c files shouldn't gain such
guards. These are commonly referred to as "header guards" for a reason.
This is the MISRA's definition of "header file" (MISRA C:2012 Revision
1, Appendix J):
"A header file is any file that is the subject of a #include
directive.
Note: the filename extension is not significant."
That's completely misleading terminology then.
I might agree with you on this, but either way this is the definition to
apply when reading the guideline. IMHO here, the best would be to use a
separate extension for "C files intended to be included" (but that's not
the point).
So, the guards are required if we want to comply with the directive,
otherwise we can raise a deviation.
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.")
Jan
It's not "some of them", it's exactly the ones used in an #include
directive, so I'm not getting your objection.
By the way, if the community agrees, I can deviate all C files and
drop the changes.
--
Simone Ballarin, M.Sc.
Field Application Engineer, BUGSENG (https://bugseng.com)
