Compatibility with MSVC #include "FILE" search order

In http://msdn.microsoft.com/en-us/library/36k2cdd4(v=vs.100).aspx
it is written:

Quoted form

The preprocessor searches for include files in the following order:

1. In the same directory as the file that contains the #include
statement.

2. In the directories of any previously opened include files in the
reverse order in which they were opened. The search starts from the
directory of the include file that was opened last and continue
through the directory of the include file that was opened first.

3. Along the path specified by each /I compiler option.

4. Along the paths specified by the INCLUDE environment variable.

In clang do we have an option to emulate the point 2?

Abramo, I don't know the answer to your question so I apologise for the
unhelpful reply, but I was a bit confused by what difference this would
make, so I'm posting in case it saves anyone else some time puzzling it
out.

Note that the Visual Studio 2005 documentation[1] is clearer as to
exactly which paths are searched: "[The double-quoted #include form
searches in] the same directory of the file that contains the #include
statement, and then in the directories of any files that include
(#include) that file".

[1] http://msdn.microsoft.com/en-us/library/36k2cdd4(v=vs.80).aspx

How are previously-opened include files found, if not by rules 1, 3 & 4?
So I guess that #2 is only to affect the *order* the paths are searched
in, rather than to add new paths that would otherwise not be searched.
Is that correct?

It seems to me that the only scenario where rule #2 has any effect is
when there are two header files with the same name, in different
directories, but not in the directory of the file #includeing it:

    A/a.c: #include "b.h"
    B/b.h: #include "c.h"
    C/c.h: #include "where.h"

With the search path -IA -IB -IC: If there are two files A/where.h and
B/where.h, rule #2 would find B/where.h. The cpp on my system (OS X
Lion) finds A/where.h.

C99 (§6.10.2) says "The named source file is searched for in an
implementation-defined manner". How annoying. :slight_smile:

Note that if where.h exists in C/, then both implementations pick
C/where.h.

Hi David,

this is an example:

$ cat p.c
#include "p.h"
$ cat q/p.h
#include "p1.h"
$ cat p1.h
$ gcc -E -I q p.c
# 1 "p.c"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "p.c"
# 1 "q/p.h" 1
In file included from p.c:1:0:
q/p.h:1:16: fatal error: p1.h: No such file or directory
compilation terminated.

If you compile it with cl.exe you get no errors, the difference is in
point #2 (i.e. p1.h is searched also in the directory of p.c)

Thanks for the example! So in addition to potentially changing the
search path order, rule #2 can also add to the search path the directory
of source files specified on the command line.

I suppose if you have: #include "subdir/x.h"
then rule #2 also adds "subdir" to the search path for files #included
by other files that were #included from x.h.