This is the mail archive of the mailing list for the libstdc++ project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

--On Wednesday, May 22, 2002 10:46:03 PM +0100 Neil Booth 
<> wrote:

> 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
>> The exception is
>>    *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?

I'd be interested to hear what other committee members thing the
language that Gaby quoted means.  I can certainly read it to mean what
Gaby thought it meant; in particular, that even if -I options are in
play you get the right header.  You can read it that way due to the
fact that all of 16.2 is essentially implementation-defined; the
paragraph Gaby's quoting seems to say "even despite all that
implementation-defined stuff, this particular usage has defined

I don't know *why* the standard would say that.  If it were up to me,
I'd certainly rather just let -I do whatever it normally does.  But,
we have to work with what we've got.

Do other people reading this have insight into what the committee
really meant here?

Mark Mitchell         
CodeSourcery, LLC     

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]