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

[Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>]

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

As I read it, Steve's main point is that the C++ standard is
inconsistent in that it forces you to break at least one promise to
the user.  The C++ standard is plain as day that errno must be
presented to the user as a macro no matter how it is implemented.
This is not optional.  According to other posts in that same thread,
Sun's implementation does not do that.  OTOH, Sun's implementation is
reported to have a completely clean global name space thus I see
Steve's line of argument on the matter.

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.
What is sane for libstdc++-v3 may or may not be the same thing that
Sun did (in fact, I hope any change in the C++ standard forces them to
change - see below).  They were attempting to ensure all identifiers
with external linkage go in namespace std.  We have been working
towards that goal, but it is unclear we are there yet.  In fact,
unless we dictate which C implementations may be used, we may never be
able to do so on all platforms.  When the C standard reserved an
identifier for external linkage but allowed a macro implementation, we
have a real problem as C++ library implementors in this area.

So, for the record, are you only taking issue with the part of the
patch which ensures errno is a macro in C++?  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.

If the problem is only with errno, then I want to apply the rest of my
patch since the errno part of my patch was only done as a curtesy to
Ben et al., along with the part that forces setjmp to be provided by
macro (since it is implemented by function on my C implementation and
many others).

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

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.

Regards,
Loren