#include_next: wrong search order?

[Alexey Neyman]

Hi Eljay,

On Friday 04 March 2005 18:12, Eljay Love-Jensen wrote:
>>The question is why the #include_next directive in syslimits.h 
>>results in including <gcc-include-dir>/limits.h, not in including 
>>limits.h from the next directory in the search list.
> 
> Because <gcc-include-dir>/limits.h is the first one in the search 
> list. 
> 
> "This directive works like `#include' except in searching for the 
> specified file: it starts searching the list of header file
> directories _after_ the directory in which the current file was 
> found."

Well, I don't see here any clue that the current file shall have the 
same name. 

> <syslimits.h> is not <limits.h>
> 
> The current <limits.h> file for the invocation within <syslimits.h> 
> had not been found yet, so it starts with the first system include 
> search path directory (i.e., <gcc-include-dir>).

Then try the following example:
- the <limits.h> header is copied from GCC include directory into 
current directory
- the preprocessor is run with 'cpp -I.'

This results in:
#include "..." search starts here:
#include <...> search starts here:
 .
 /usr/local/include
 /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/include
 /usr/include

Headers used:

. limits.h
  #include "syslimits.h"
.. /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/include/syslimits.h
   #include_next <limits.h>
... /usr/include/limits.h

This way, you see, the #include_next directive results in including 
from the directory _after_ the one <syslimits.h> resides in. If your 
statement had been true, cpp would have included limits.h from 
current directory again (since it is included from a header with a 
different name).

Before you ask it: running 'cpp -isystem .' gives exactly the same 
result.

Regards,
Alexey.



-- 
We are intelligent and clever, though you would never call us cunning.
                        -- Spathi, SC2