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
On Friday 18 March 2005 14:14, Neil Booth wrote:
> Alexey Neyman wrote:-
>
> > Well, at least this contradicts to what 'make cpp' says. Its
> > occasional user won't have knowledge of its internals, therefore
I'd
> > view this behavior as rather puzzling: the search path list states
> > that directories dir1, dir2, dir3 are searched in that order; but
> > #include_next from a file in dir2 finds the included file in dir2
> > again.
>
> The prepending rule is documented. The description of #include_next
> might be improved to specifically refer to the include path; rather
> than implicitly as it currently does.
How about this patch then?
Regards,
Alexey.
--
All are welcome to our nest.
We are Pkunk, we cannot help but love all.
-- Pkunks, SC2
2005-03-18 Alexey Neyman <alex.neyman@auriga.ru>
* doc/cpp.texi (Wrapper Headers): Clarify the behavior of
#include_next in case that the current file was included
in quotes.
*** gcc.orig/gcc/doc/cpp.texi 2005-03-18 15:36:43.000000000 +0300
--- gcc.work/gcc/doc/cpp.texi 2005-03-18 15:35:56.000000000 +0300
***************
*** 1091,1096 ****
--- 1091,1111 ----
file named, starting with the directory in the search path after the one
where the current file was found.
+ Note that the same directory may appear more than once in the search
+ list if the current file is included in quotes. For example, the directory
+ explicitly specified on the command line could also be prepended to the
+ search path list as the directory of the current file (@pxref{Include Syntax})@.
+ If this is the case, #include_next may find the same file again. To circumvent
+ this obstacle, the following wrapper could be used:
+ @smallexample
+ #if !defined(__HEADER_H_)
+ #define __HEADER_H_
+ /* Actual code with #include_next <header.h> somewhere in it. */
+ #else
+ #include_next <header.h>
+ #endif
+ @end smallexample
+
The use of @samp{#include_next} can lead to great confusion. We
recommend it be used only when there is no other alternative. In
particular, it should not be used in the headers belonging to a specific