This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: cpp include bug
- To: Dan Nicolaescu <dann at godzilla dot ICS dot UCI dot EDU>
- Subject: Re: cpp include bug
- From: Zack Weinberg <zack at wolery dot cumb dot org>
- Date: Sat, 27 May 2000 17:30:41 -0700
- Cc: gcc-bugs at gcc dot gnu dot org
- References: <200005262214.aa20461@gremlin-relay.ics.uci.edu>
On Fri, May 26, 2000 at 10:14:47PM -0700, Dan Nicolaescu wrote:
...
> It looks like the preprocessor thinks that it should not preprocess
> "endian.h" after it has seen #include <endian.h>
Yep. This looked like a simple bug at first, but turns out to be
nasty on deeper inspection.
To determine if a header file has already been seen, we look it up in
a hash table by its "short name" - which is endian.h in both cases.
The table entry has a pointer to the location in the search path where
it was found. If that location is reachable by walking along the path
for this #include, the header is considered already-seen. There are
then additional checks for whether it is to be scanned again.
The include path for your example looks something like this:
"" starts here:
.
<> starts here:
/usr/include
<endian.h> is found in /usr/include. "endian.h" _could_ be found in
/usr/include, so we assume it's the same header - but neglect to
consider the possibility that there's a header in . which was never
examined.
There is no simple fix with the current data structure. I'm going to
redesign it. Unfortunately that means a patch won't be immediately
forthcoming.
zw