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

David Röthlisberger david at rothlis.net
Fri Nov 9 03:45:19 PST 2012


On 9 Nov 2012, at 11:24, Abramo Bagnara wrote:
> Il 09/11/2012 11:51, David Röthlisberger ha scritto:
>> 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.
> 
> 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.





More information about the cfe-dev mailing list