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

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

OK, agreed.  This is why anything that could be a macro must be a
macro in C++.  If a symbol, optionally provided by a macro, was not a
macro that mapped to names in the implementor space, then the global
name space would be polluted.  C didn't concern itself with such issues.

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

Without regard to anyone's particular complain that different sections
of the C++ standard conflict with one another...

Here is where I get confused again but I suspect that it is because we
have different assumptions in mind.  Assumption: I already have a C
implementation that doesn't honor any C++ global name space rules.
Assume that my goal is to adhere to as many clauses of ISO 14882:1998
as possible without throwing away my entire C library.

For reference, here is section 17.4.1.2 clause 5 of ISO 14882:1998:

``Names which are defined as macros in C shall be defined as macros in
  the C++ Standard Library, even if C grants license for
  implementation as functions [Note: the names defined as macros in C
  include the following: assert, errno, offsetof, setjmp, va_arg,
  va_end, and va_start. - end note]''

Are you honestly telling me that there is no agreement between
committee members that the above quoted section has the obvious
meaning?  To me, errno is explicit listed as being a macro under C++!

The name of this thread is ``Adhere to section 17.4.1.2 clause 5 of
ISO 14882:1998''.  I really don't understand your comment that
"[t]here is no agreement on what [errno] should be (contrary to the
subject of this thread :-)".  Also, I could find no other section that
explicitly claims that errno should be something other than a macro.

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

Not until someone takes an active interest in global name space
cleanliness.  Even then, I argue that my patch makes the problem no
worse than it currently is.  Do you disagree?

Here is the argument: The C library, upon which we are already
layered, exposes errno [FreeBSD's library actual has this problem with
setjmp but the logic must be the same for any library that has a
problem with errno instead] as a identifier with external linkage not
a macro.  Without doing anything tricky, there is nothing the C++
library can do to stop it (at least, it is an orthogonal problem to
the one I am addressing and my patch doesn't preclude that other
problem being solved later for some platforms).  We can at least
adhere to some additional clauses of the standard.  That is all my
patch does.  If the committee changes that clause, then I hereby
promise that I will attempt to track the issue.

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

Well, libstdc++-v3 should just close up shop and go home then.  I
guess we all have been wasting our time and effort in that goal.

I don't buy it. (and getting rid of libio dependencies proves the
exact opposite of your claim ;-).

Have a nice weekend (I am off-list until Monday),
Loren