This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: PATCH: Adhere to section 17.4.1.2 clause 5 of ISO 14882:1998
On Fri, Apr 06, 2001 at 07:49:01PM -0500, Loren James Rittle wrote:
> 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++!
Twice, in fact. This supposed lack of agreement is just confusion on
Gaby's part. Steve is pretty clear that it says it has to be a macro,
but that it unfortunately misdescribes the C standard. I hope to see
that latter fixed myself, not least to prevent confusion such as Gaby's.
> > 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 ;-).
No, it's really _not_ possible to build a conforming library on top of a
set of entirely unknown C headers. Simply, C implementers are allowed
to shovel all kinds of stuff into their headers that break ours, and
they do, routinely.
It's unfortunate, but not fatal; it just means some cleanup work in
the shadow headers for known target C libraries. There's a little bit
of it there now, for cleaning up glibc bits, mainly for example --
probably what's there could be done a lot better some other way.
Most C libraries are very stable, and reasonably clean, so not a huge
amount needs to be done to build and maintain a port onto a given C
library (unless you hope to use its native locale data!).
Nathan Myers
ncm at cantrip dot org