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 11:00:01PM +0200, Gabriel Dos Reis wrote:
| > Zack Weinberg <zack@codesourcery.com> writes:
| > | 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. 
| 
| Every program that deliberately puts its own version of a standard

Not every files CPP happens to encounter in its way is deliberately
put there by the user.

[...]

| I do not have numbers on how many such programs there are, but I am
| confident that there are plenty, and that "fixing" them will not be
| easy.  Start with Xfree86.

You're missing the entire point.  The proposal is this:  A flag
--no-standard-headers maintains the actual (non-comforming)
behaviour.  When turned off it delivers the expected (== standard)
semantics.  As such existing programs abusing of that non-conforming
behaviour have the old semantics when turned on.  Nothing breaks.

| > | > 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.
| 
| No, it gets it right.

No, it doesn't.  Have look at the quote I provided.

-- Gaby