Redundant conditional inclusion macros?

[Aculaniveus]

Hi guys, I'm looking into the MINIX 3 source code and I often see things like

#ifndef _ANSI_H
#include <ansi.h>
#endif

even though the file ansi.h was "guarded" with

#ifndef _ANSI_H
#define _ANSI_H

/* ansi.h contents */

#endif /* _ANSI_H */

Isn't the effect of the first snippet equal to just?

#include <ansi.h>

Is that to avoid making the compiler open the file to see if it was already included, to protect
against not "guarded" files, or just bad style? I'm just curious.

Thanks

[claudiu]

An include preprocessor command is basically a copy paste of the file you are including. The guards as you noticed are a way to prevent a file to include the same thing multiple times and create conflicts. If you included file1.h in file2.h and then included both file1.h and file2.h in file3.h without the guards you would get an error because stuff declared in file1.h is declared multiple times, once in file1.h and once in file2.h.

As for what you pointed out, yes, the Minix instructions seem a bit redundant. My guess is that there were multiple developers of that library with different styles.

[laserlight]

Is that to avoid making the compiler open the file to see if it was already included, to protect
against not "guarded" files, or just bad style?

The former is most likely the intent, but it is not very useful on modern compilers that can avoid including the file's contents as soon as the guard is detected at the top of the file.

You cannot protect against "not guarded" files in this way.

It is bad style because it requires the file that is included and all the files that include it to agree on the inclusion guard identifier.

[Aculaniveus]

Thanks for the replies guys.

You cannot protect against "not guarded" files in this way.

I see, after all after

#ifndef _ANSI_H
#include <ansi.h>
#endif

_ANSI_H is still undefined if ansi.h doesn't define it.