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

[Gabriel Dos Reis <gdr at codesourcery dot com>]

Zack Weinberg <zack@codesourcery.com> writes:

| On Wed, May 22, 2002 at 09:33:29PM +0200, Gabriel Dos Reis wrote:
| > | 2. Creating header files with the same names as system headers, and
| > | injecting them into the search path ahead of the system headers, is
| > | common practice
| > 
| > I do not disregard that practice; that is why I said we provide
| > an option to tell the compiler not give the standard meaning standard
| > headers have.
| 
| Thinking about it, my entire position on this issue can be summed up
| thus: That option already exists, and its name is -I <path>.

That is trying to put unrelated issues into the jacket and that breaks
required semantics; therefore I don't that the option I'm talking
about has the name you think.

| Furthermore, any change in this area will break an uncertain but large
| number of user programs.

I don't a change in line to implement the required semantics will
brack user programs.  Not implementing the required semantics is
causing more troubles than it should.

|  The benefits of the change, meanwhile, are
| minimal.

I disagree.  The benefits aren't minimal.  The benefist is a much more
robust and usable compiler.  That benefit can't be minimal.

[...]

| > If the user intentionally chooses to inject home-grown headers in
| > place of standard ones, then that shouldn't be something the compiler
| > should discover accidently; it should be something that it knows about
| > because of appropriate options on invokation line.
| 
| Let me reiterate that the compiler does not "discover it accidently".

Certainly, it does, which bring the problems in the first place.

| The compiler knows that the user wants their home-grown headers to be

In this cas, it doesn't.  It gets it wrong, because it implements the
wrong semantics.

| Anything else is second-guessing the user,  which I object to.

No, it is not implementing the required semantics that is being
second-guessiing. 

I've provided reference as to why we're not implementing the required
semantics.  

-- Gaby