This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [RFC] libstdc++/6720 and libstdc++/6671
- From: Jason Merrill <jason at redhat dot com>
- To: Gabriel Dos Reis <gdr at codesourcery dot com>
- Cc: Mark Mitchell <mark at codesourcery dot com>,Zack Weinberg <zack at codesourcery dot com>,Neil Booth <neil at daikokuya dot demon dot co dot uk>,Nathan Myers <ncm-nospam at cantrip dot org>,"libstdc++ at gcc dot gnu dot org" <libstdc++ at gcc dot gnu dot org>
- Date: Thu, 23 May 2002 11:55:59 -0400
- Subject: Re: [RFC] libstdc++/6720 and libstdc++/6671
- References: <m3vg9hcq7m.fsf@merlin.nerim.net><146990000.1022091342@gandalf.codesourcery.com><m3sn4kyow2.fsf@merlin.nerim.net>
>>>>> "Gabriel" == Gabriel Dos Reis <gdr@codesourcery.com> writes:
> The exception is 17.4.3.2:
> *If* a file with a name equivalent to the derived file name for one of
> the C++ Standard Library headers is *not provided* as part of the
> implementation, *and* a file with that name is placed in any of the
> standard places for a source file to be included (16.2), the behavior
> is undefined.
I believe the above is the result of an editing error. C99 says (in 7.1.2):
If a file with the same name as one of the above < and > delimited
sequences, not provided as part of the implementation, is placed in any of
the standard places that are searched for included source files, the
behavior is undefined.
I think someone was trying to simplify this construction and ended up
changing the meaning. The September 1994 working paper says,
If a file has a name equivalent to the derived file name for one of
the Standard C++ library headers, is not provided as part of the
implementation, and is placed in any of the standard places for a
source file to be included, the behavior is undefined.
Which has the same meaning as the C99 formulation, though it is not as
clear. This seems to have changed between the April and October 1995
working papers.
Jason