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

[Neil Booth <neil at daikokuya dot demon dot co dot uk>]

Gabriel Dos Reis wrote:-

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

Sure.  But how is this different from any other switch you might
provide G++ like -I. or -ffast-math?  My point being that unless
your command line options are *just* -ansi -pedantic (or equivalent)
you're effectively giving the implementation leave to do whatever
it documents for those options.

And we *do* do just what we document for -I.

I'm against changing anything in include semantics.  They're already
over-specified and over-complicated.

Neil.