This is the mail archive of the libstdc++@gcc.gnu.org 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]

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


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