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

[Gabriel Dos Reis]

Zack Weinberg <zack@codesourcery.com> writes:

| Gabriel Dos Reis wrote:
| > Neil Booth wrote:
| > | Gabriel Dos Reis wrote:
| > | >
| > | >     #include <cmath>
| > | >     int main()
| > | >     {
| > | >        double x = std::sin(9.8);
| > | >     }
| > | >
| > | > should not provoque compilation error just because there happens to be
| > | > a file named cmath in the current directory.  Cure that problem and
| > | > the symptoms with go away.
| > |
| > | I don't agree with your solution of special-casing certain header names,
| >
| > It is not me who is special-casing certain header names.  That special
| > meaning of certain headers are built into the language.  Failure to
| > provide the expected meaning is failure to implement the language.
| 
| I disagree on three grounds.
| 
| 1.  Good software does not second-guess the user.

I agree.  But Good software does deliver expected semanticcs.


|  If the user has
| specified -I. or -I/usr/include/g++-3/ext or whatever, they bloody
| well meant it, for good or ill.

I can't agree with that.  We do give users advise to say
-I/usr/include/g++-3/ext and that happens to break semantics. 

|  You can think of -I. as invoking a
| non-conforming mode of the compiler if it makes you feel better.

I disagree with that view.  Whereas the standard doesn't forbid
useless implementations, it does specify in our specific cases what we
should do.  We implement standard headers in terms of actual files,
therefore we have to take the appropriate steps to ensures that the
semantics are respected.

| 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.

| -- to work around bugs or provide portability
| wrappers.  In other words, I can guarantee that if we implement the
| semantics you want, we will have users demanding it be un-done.

No, I think you missed my point 3) in the description, which talks
about the switch to turn off standard-conformant interpretation.

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.


| 3. The list of headers you want special-cased is ill-defined.

No, it is not.  We're talking of C++98 and its standard header.  The
set of those standard headers is well-defined.  For a hosted
implementation, it is part of the language.

| Obviously it includes the headers defined by C89 and C++98.

Yes.

|  Do you propose to include C99 headers also?

No.  Which parts of C99 go into C++ is not well defined currently,
even if we could make guesses about some portions.  And in which forms
they'll get in C++0x is currently unknown.

|  What about POSIX.1, .1a, .1b, | etc? SUS v2? v3?  The Austin
| drafts?  The X11 reference spec? 
 
All, out of the scope the behaviour mandated by the standard.
If you want to include them, I have no objection.  But there are not
of concerns here, because they are not part of the language.

| And
| what happens if the system in use does not include some of the headers
| in the set you pick?

Libstdc++-v3 provides the set of headers mandated by the language
definition. 

| Nathan is correct:  This is entirely and only an issue of naming
| conventions.

May be, may be not.  But our business is to provide a conformant and
robust tool.  As such, we should prevent any names clashes since we do
implement standard headers in terms of actual files.

-- Gaby