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

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

Mark Mitchell <mark@codesourcery.com> writes:

[...]

| > The plan for CPP for understanding standard header names is as follow:
| >
| >   1) if the header name <xxx> is known to be standard then it is
| >      searched in the appropriate directory
| 
| EDG uses some minor magic in this area.  In particular,
| 
|   #include <foo> // No extension!
| 
| matches either "foo.stdh" or plain "foo".

I guess they're trying .stdh (and not .h or similar) in order to match
the standard requirements (see below) and void pitfalls.  That at
least makes my point:  We should be very careful about the way we're
mapping standard headers to actual files.  Just having 
<xxx> -> <bits/xxx.h> is  insufficiant. 

| 
| We could also do something like that; search for "foo.stdh" first, and
| then, if you don't find it, fall back to "foo".  It's not clear that's
| better than your scheme, just different.
| 
| Gaby, does the standard actually say that:
| 
|   #include <cmath>
| 
| always gets the "right" cmath?

The standard does specify the effect of #include <cmath> in a program
(with on exception, see below): it should make the declarations given
in section 26 available to the program.
The specification of all standard headers is given in 17.4.1.2.

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. 

(Emphasis is mine).  Therefore, the contexts in which the compiler is
granted right to transmute semantics is very limited:

   1) the implementation _doesn't_ provide a file derived from a
      standard header as part of its implementation. *and*

   2) a file with a name derived from a standard header should be
      placed in any of the standard places for a source file to be
      included.

Since we're not doing 1) (i.e. we implement standard headers in terms
of actual files), we're not in case where we could legitimately invoke
undefined behaviour; that is we have to deliver the semantics
according to 17.4. and 16.2 -- we must find the "right" <cmath>.

| I don't see anything that implies that.  It says that their needn't
| actually be a file named "cmath".  It also says that you can search
| however you please when you see "<xxx>".  But I don't see that it
| says that a conforming program can rely on "#include <cmath>" always
| getting the right cmath; everything about how to find headers is
| implementation-defined.

Certainly, how a compiler chooses to map a standard header into a
actual files is implementation defined.  However, it shouldn't
transmute the semantics of #include <xxx> when <xxx> is a standard
header and we do implement <xxx> in terms of files whose names are
derived from <xxx>.  The paragraph "17.4.2 Using the library" says:

   This subclause describes how a C++ program gains access to the
   facilities of the C++ Standard Library. 17.4.2.1 describes effects
   during translation phase 4, while 17.4.2.2 describes effects during
   phase 8 (2.1). 

17.4.2.1 Headers

1 The entities in the C++ Standard Library are defined in headers,
  whose contents are made available to a translation unit when it
  contains the appropriate #include preprocessing directive (16.2). 


We have to make that content available.

-- Gaby