This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

#include_next: wrong search order?


[Please keep me in CC:]

below is a result of running cpp on a simple source that contains
just "#include <limits.h>" (numbers before # added by me for further

[1] # 1 "y.c"
[2] # 1 "/usr/lib/gcc-lib/i386-redhat-linux/3.3.3/include/limits.h" 1 3 4
[3] # 11 "/usr/lib/gcc-lib/i386-redhat-linux/3.3.3/include/limits.h" 3 4
[4] # 1 "/usr/lib/gcc-lib/i386-redhat-linux/3.3.3/include/syslimits.h" 1 3 4
[5] # 1 "/usr/lib/gcc-lib/i386-redhat-linux/3.3.3/include/limits.h" 1 3 4
[6] # 122 "/usr/lib/gcc-lib/i386-redhat-linux/3.3.3/include/limits.h" 3 4
[7] # 1 "/usr/include/limits.h" 1 3 4
[8] # 26 "/usr/include/limits.h" 3 4
    /* snip */

The files do the following:
<gcc-include-dir>/limits.h does '#include "syslimits.h"'
<gcc-include-dir>/syslimits.h does '#include_next <limits.h>'

The description for the #include_next in the states:
"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

Therefore, it appears that the lines [5] and [6] are wrong:
<syslimits.h> resides in /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/include/
and therefore the search for #include_next should have commenced at
the next system include directory, that is /usr/include.

Why does GCC first pick up the limits.h from the same directory as the
<syslimits.h> file? Is it a bug?

PS. x86, Fedora Core 2, tested with GCC 4.1 also - with the same effect.


Do you sleep with your window unlocked? Be seeing you...
                        -- Arilou, SC2

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]