In gcc's syslimits.h (gsyslimits.h), we do:
/* syslimits.h stands for the system's own limits.h file.
If we can use it ok unmodified, then we install this text.
If fixincludes fixes it, then the fixed version is installed
instead of this text. */
#define _GCC_NEXT_LIMITS_H /* tell gcc's limits.h to
recurse */
#include_next <limits.h>
#undef _GCC_NEXT_LIMITS_H
and this can find a user limits.h in a directory named with -iquote
whenever -I- isn't used. The user wishes to not so find that file, as
it breaks <limits.h>/<syslimits.h> on the system.
The doc says:
@samp{#include_next} does not distinguish between @code{<@var{file}>}
and @code{"@var{file}"} inclusion,
but at the same time:
@item [EMAIL PROTECTED]
@opindex iquote
Add the directory @var{dir} to the head of the list of directories to
be searched for header files only for the case of @samp{#include
"@var{file}"}; they are not searched for @samp{#include <@var{file}>},
otherwise just like @option{-I}.
I'd be tempted to say that include_next could be bug fixed to notice
<>/"" and DTRT and document it as such.
What do others think?
1 Fix include_next
2 Tell user to use -I- (and undeprecate -I-).
3 Nothing, tell user to not try and use "limits.h" for anything.
4 Fix syslimits.h to `do something else'. (I have no clue what.)
