Re: Interesting -iquote bug

[Ian Lance Taylor <iant at google dot com>]

"Dave Korn" <dave.korn@artimi.com> writes:

>   Here's one: it doesn't involve -iquote, but I think it illustrates the same
> problem.

The problem which Mike described had to do with #include_next.  So I
don't think this is the same problem.

>   One of the STL headers finds our user-appplication debug/debug.h instead of
> ./debug/debug.h, which is what it expects to find (umm, I don't really mean
> "." in the $PWD sense, I mean it in the sense of the directory where the STL
> header lives).

I would describe this as a bug in the libstdc++ header files.  They do
this:

#include <debug/debug.h>

That is a bad idea because if the user uses a -I option which happens
to point to a debug/debug.h file, the wrong debug.h file will be
picked up.

The libstdc++ header files should probably do this:

#include "debug/debug.h"

Then the search will start from the location of the libstdc++ header
file, and the preprocessor will always find the right header file.
This is a consistent issue throughout the libstdc++ header files.

>   It used to be possible to work around this problem by using -I- to split the
> path and relying on <> includes to only pick up on system files.  That's not
> always an option ever since the change that made -I- /also/ prevent include
> files located side-by-side in the same directory from finding each other
> without a full path.

Yes, and the -I- option has been deprecated because it doesn't do the
right thing.

Instead, we have -iquote.  And we are currently missing
-idisable-the-directory-of-the-including-file, which is a bug.

Unfortunately, using -idisable-the-directory-of-the-including-file
will break my suggestion of using #include "" in the libstdc++ header
files.  But using #include <> in those header files is also wrong.
I'm not sure how to resolve that.

Ian