Dir 4.10: Is a different form of the include guard considered a violation of the directive?

Moderators: misra-c, david ward

Post Reply
GerlindeKettl
Posts: 9
Joined: Thu Apr 15, 2010 8:01 am
Company: Continental AG

Dir 4.10: Is a different form of the include guard considered a violation of the directive?

Post by GerlindeKettl » Thu Mar 29, 2018 1:36 pm

The example of Directive 4.10 "Precautions shall be taken in order to prevent the contents of a header file being included more than once" says that in order to facilitate checking, the contents of the header should be protected from being included more than once using one of the following two forms:

Code: Select all

<start-of-file>
#if !defined ( identifier )
#define identifier
/* Contents of file */
#endif
<end-of-file>

<start-of-file>
#ifndef identifier
#define identifier
/* Contents of file */
#endif
<end-of-file>
I got software from a third party which uses the first form, but the parentheses are a bit differently placed:

Code: Select all

#if ( !defined identifier )
As I consider this include guard correct from a functional point of view, is this nevertheless a violation of Dir 4.10 because it does not use one of the two forms listed in the example?

misra-c
Posts: 555
Joined: Thu Jan 05, 2006 1:11 pm

Re: Dir 4.10: Is a different form of the include guard considered a violation of the directive?

Post by misra-c » Tue Apr 24, 2018 9:33 am

#if (!defined identifier) does not violate directive 4.10.

Dir 4.10 is a directive which means a full description is not provided ( see Section 6.1) Static analysis tools may assist in checking compliance of directives, but different tools may place different interpretations on what constitutes a non-compliance.

The purpose of the Directive is to prevent multiple inclusion of an Include file, and while the examples provided are informative only, any other form of Include Guard is compliant.

However, it is accepted that the two forms shown as examples that are most commonly checked by static analysis tools. Therefore the user is encouraged to use those forms where possible.
---
Posted by and on behalf of
the MISRA C Working Group

Post Reply

Return to “7.4 Code design”