Re: #include_next: wrong search order?

[Alexey Neyman <alex dot neyman at auriga dot ru>]

Hi Eljay,

On Friday 04 March 2005 15:32, you wrote:
> Hi Alexey,
> 
>  >Therefore, it appears that the lines [5] and [6] are wrong:
> 
> It doesn't appear wrong to me.
> 
> When a #include is done (or the GCC 
> behind-the-covers-don't-use-this-in-your-code #include_next), it pulls in 
> the specified file as if embedded, then returns back to processing the 
> first file.  That's what I see in your y.c result.
> 
> FYI - you can see your system include path via "gcc -E -v y.c".

As you might have noticed, I ran cpp; that's the same.

You must have misunderstood the question. What surprises me is that
"#include_next <limits.h>", invoked from <gcc-include-dir>/syslimits.h
actually results in including <gcc-include-dir>/limits.h instead of
including /usr/include/limits.h.

Please re-read the quote from the 'info cpp': cpp should have
started the search with the directory _after_ the one containing
syslimits.h. That should be /usr/include, given that 'cpp -v'
outputs the following search order:

#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/include
 /usr/include
End of search list.

Any clues?

Regards,
Alexey.

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