[cfe-dev] Compatibility with MSVC #include "FILE" search order

[David Röthlisberger]

On 9 Nov 2012, at 09:27, Abramo Bagnara wrote:
> In http://msdn.microsoft.com/en-us/library/36k2cdd4%28v=vs.100%29.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. :-)

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