Re: PATCH: Adhere to section 17.4.1.2 clause 5 of ISO 14882:1998

[Gabriel Dos Reis <Gabriel dot Dos-Reis at cmla dot ens-cachan dot fr>]

Loren James Rittle <rittle@latour.rsch.comm.mot.com> writes:

| [Removing gcc-patches@gcc.gnu.org until this is sorted out.]
| 
| > | Assuming a liberal reading of this section, errno should be provided
| > | as a macro even if the C implementation is something other than a
| 
| > is that errno has an external linkage, thus it cannot be a macro
| > name. 
| 
| After one round of private e-mail on this matter, I fully admit that I
| may not understand the problem space as well as Gabriel does.
| However, I will attempt to change his mine on the root issue and
| explain why we can, in good faith, decide the issue another way than
| Sun (at least until the committee rules).
| 
| Just because an identifier such as errno is reserved for external
| linkage under C does not mean that it can't be a macro under C++.  I
| feel that the issue raised, especially the angle played by Steve's
| post to comp.std.c++, has far more to do with clean-up of the global
| name space than with what must absolutely be a macro under C++.

Because of scoping rules and C++ syntax, the line between the set of
macro names  and that of non-macro names needs to be drawn in a
precise way.  Much more than in C.

I'm not arguing we should do what Sun does.  But we should aware of
what other implementors are doing (and Sun is one of them).

[...]

| With all the input I now have, my opinion is that until the committee
| decides the issue one way or the other, we should do something sane.

Agreed.

[...]

| So, for the record, are you only taking issue with the part of the
| patch which ensures errno is a macro in C++? 

I was primarily commenting on the errno part.  There is no agreement
on what it should be (contrary to the subject of this thread :-) and I
find Steve's argumentation quite convincing even though I do not
necessarily agree with all of his proposals. 

| ... I ask since it seems
| that we have the exact same problem with all other identifiers that
| may be optionally provided by macro or identifier with external
| linkage.  Especially, if we are going to allow the C implementation to
| provide the implementation of the identifier.

We need to ensure that they are either macros or else identifiers with
external linkage.

[...]

| Following logic, if the errno part of my patch is rejected, then we
| must change testsuite/17_intro/header_cerrno.cc to either (a) ensure
| that errno is *not* a macro (at least that is what Gabriel explicitly
| claims in the quoted region above unless I misquoted him or misread
| him) or (b) remove that test entirely until the C++ committee decides
| which to do.  BTW, if the C++ committee decides that errno must not be
| provided by macro, they will break at least a few existing
| implementations and ensure that adding thread support is harder to do
| than necessary under both C and C++...

Yes, that is a key data point.

| If the problem is with all such conversions to macros of identifiers
| that are optionally macros in C in order to support requirements of
| the C++ standard, then I think we must explicitly decided which
| feature is more important to us.  However, either way, if we say we
| are building a C++ library that can sit on top of many C library
| implementations without intrusive knowledge of that library, then it
| seems wrong to test for features that we have no desire to fix up in
| the C++-wrapper header files.

Experience shows that we cannot build a C++ library on top of a C
implementation without intrusive knowledge of that library :-(

-- Gaby