Re: [RFC] libstdc++/6720 and libstdc++/6671

[Alexandre Oliva <aoliva at redhat dot com>]

On May 22, 2002, Zack Weinberg <zack@codesourcery.com> wrote:

> On Wed, May 22, 2002 at 07:30:34PM +0200, Paolo Carlini wrote:
>> >ext/algorithm includes <algorithm>
>> >If this is changed to include "algorithm" will the preprocessor include
>> >ext/algorithm from the current dir, or spot that that's the current file
>> >and then proceed to look in the system dirs, finding the intended header?
>> 
>> Sorry, now I get your point, but this could easily be solved by including
>> "../algorithm", do you agree?

> Yes to both -- #include "algorithm" will find the same file again
> (sometimes people genuinely want to do that) and
> #include "../algorithm" will do what you want.

Now, what if the user actually intends to replace one the header files
that is included by a standard header file?  I.e., <foo> includes
<bits/bar.h>, and the user thinks there's a bug in bits/bar.h and
wants to replace that?  If foo had `#include "bits/bar.h"', you'd be
preventing this kind of replacement.

OTOH, if foo had `#include <bits/bar.h>', how would the compiler be
able to tell whether the user meant to replace the standard
bits/bar.h, or just accidentally chose a header file name that the
developers of libstdc++-v3 happened to choose too?

My suggestion is that, whenever a *system* header file includes
another header file using angle brackets, we search only the system
header files (or perhaps search them first).

Then, -I flags won't get bits/bar.h accidentally replaced, but
-isystem will still allow users to do it if they really mean it.

This doesn't solve the problem of including standard headers from the
main program.  One could still replace them by having a file with the
same name in one of the `-I'ed directories.  It seems to me that the
only way to overcome this problem is to have the preprocessor know a
list of standard headers, that, when included with angle brackets, it
would search in -I directories, but warn instead of including them.
Such standard headers could still be replaced by a user by means of
-isystem, and the user would get a warning in case the intent was to
have a system header file replaced using -I.

Can anyone see any flaw in these ideas?

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer