This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Interesting -iquote bug
- From: Ian Lance Taylor <iant at google dot com>
- To: Mike Stump <mrs at apple dot com>
- Cc: GCC Mailing List <gcc at gcc dot gnu dot org>
- Date: 26 Sep 2006 17:48:55 -0700
- Subject: Re: Interesting -iquote bug
- References: <9D5CD279-4E26-4054-B2F5-280C4D1637F9@apple.com>
Mike Stump <mrs@apple.com> writes:
> 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.
My understanding has always been that #include_next should find a
version of the header file farther down the search path. So if gcc's
limits.h was found via #include <limits.h>, then the #include_next
should not find a #include "limits.h", it should find the next
<limits.h>.
And that is pretty much what the documentation says. And I don't
think that behaviour should change in any way.
So I don't understand what the issue is. Can you give an example?
Ian