Hi,
[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
references):
[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 cpp.info 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
found."
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.
Regards,
Alexey.
--
Do you sleep with your window unlocked? Be seeing you...
-- Arilou, SC2
