[RFC] libstdc++/6720 and libstdc++/6671
Neil Booth
neil@daikokuya.demon.co.uk
Wed May 22 14:49:00 GMT 2002
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.
More information about the Libstdc++
mailing list