Path: utzoo!telly!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!augean.oz.au!mpope
From: mpope@augean.oz.au (Michael T Pope)
Newsgroups: gnu.gcc.bug
Subject: cpp bug
Message-ID: <8907131219.8989@munnari.oz.au>
Date: 14 Jul 89 03:48:50 GMT
Sender: daemon@tut.cis.ohio-state.edu
Distribution: gnu
Organization: GNUs Not Usenet
Lines: 36

(Gcc/G++ 1.35, Sun 4, SunOS 3.x)
The GNU C preprocessor can get confused by an odd combination of
-I arguments and use of #include <foo> versus #include "foo".
(The problem surfaced using G++, hence the C++ references.)

Imagine two neighbouring source directories, src-1 and src-2.  src-1
contains several include files, one of which is perversely named
"stream.h".  Other files in src-1 use the local stream.h with #include
"stream.h", and the system version with #include <stream.h>.  So far
so good.

Now the files in src-2 require many of the include files in src-1.
One might suspect that to compile src-2/foo.C one could try---

g++ -c -I../src-1 -I- foo.C

---the intention being to search src-1 for #include "foo" forms only.
Now foo.C contains a line #include "bar.h", where bar.h is
in src-1.  src-1/bar.h gets picked up correctly, but from thereon the
rot sets in--- bar.h contains a line #include <stream.h>, but the
file that is included ultimately into foo.C is src-1/stream.h not the
system include version as one might hope the <>s indicate.

Silly choice of file names I admit.  Anyway here is the fix.

The problem is due to the variable "first_bracket_include" not being
correctly initialized in cccp.c:main().  Fix by adding at line 289---

    if (ignore_srcdir && first_bracket_include==0) {
      first_bracket_include = (cplusplus) ? cplusplus_include_defaults 
      : include_defaults;
    }


Cheers,
Mike Pope