This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Wrong search order for #include_next
- From: Neil Booth <neil at daikokuya dot co dot uk>
- To: Alexey Neyman <alex dot neyman at auriga dot ru>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Fri, 18 Mar 2005 19:18:02 +0900
- Subject: Re: [PATCH] Wrong search order for #include_next
- References: <200503181150.24666.alex.neyman@auriga.ru>
Alexey Neyman wrote:-
> The problem arises when an #include_next directive is used from a file that
> was included in quotes itself. In this case, this means:
>
> tst.c: #include <limits.h>
> $GCCINC/limits.h: #include "syslimits.h"
> $GCCINC/syslimits.h: #include_next <limits.h>
>
> The problem is that the paths supplied to the cpp_set_include_chains() routine
> are not inserted into the directory hash. Therefore, when syslimits.h is
> included, a new cpp_dir entry is created and prepended to the quote_include
> list by the make_cpp_dir() routine. The resulting search path list looks
> like:
>
> [$GCCINC] --> [/usr/local/include] --> [$GCCINC] --> [/usr/include]
>
> The syslimits.h file is found in the 1st entry ($GCCINC) and retains a pointer
> to that entry in its 'dir' field. When the `#include_next <limits.h>' is
> attempted, the search starts at the dir->next directory, which
> is /usr/local/include in this example. Therefore, the <limits.h> is found in
> the 3rd entry, which is again $GCCINC.
This is intended behaviour. Once you have #include "" the include chain
is prepended with the current directory, and searching starts there.
Since that is where in the include chain it was found, #include_next
correctly starts after that point.
The real bug is the use of "" includes in what appears to be a system
header. limits.h should angled includes.
Neil.