This is the mail archive of the
mailing list for the libstdc++ project.
Future evolution of c++config.h and _GLIBCXX_USE_LONG_LONG
- From: Matt Austern <austern at apple dot com>
- To: libstdc++ at gcc dot gnu dot org
- Date: Tue, 11 Jan 2005 14:46:42 -0800
- Subject: Future evolution of c++config.h and _GLIBCXX_USE_LONG_LONG
Apple has to make a decision about how to handle "long long" in the
Darwin C library issues. I suspect we aren't the only OS vendor with
this problem. Which decision we make depends a lot on what sort of
evolution we expect in libstdc++ configury.
At an abstract level, the basic problem is that Libc (part of the OS
for us, as it is for many vendors) and libstdc++ handle configuration
issues a little differently. A crude simplification that I hope isn't
too crude: libstdc++ expects you to make decisions at the time the
library is configured, and Libc expects you to make decisions at the
time you compile the header.
Or to take it down from the realm of the abstract to the concrete: our
Libc headers have a fair amount of preprocessor logic to decide whether
to expose long long functionality, e.g. things like strtoull and
lldiv_t. This sort of logic is necessary, since these headers are used
for multiple languages and different conformance scenarios. Every
production C library I've seen does something of the sort. What we
need to decide is: what should this logic do when these headers are
being compiled as C++?
libstdc++ governs this with the _GLIBCXX_USE_LONG_LONG macro in
c++config.h. It's set at the time libstdc++ is configured. On Darwin
the default is for it to be 1, which I think is quite correct.
Obviously we need to make sure that Libc and libstdc++ are consistent,
since we'll get errors if c++config.h tells libstdc++ to use long long
but the C library headers don't provide it. So we need to make sure
that Libc defines long long functionality whenever Libc is being used
by a default-configured libstdc++. How to do that?
That's where I start getting nervous. I see two options, and I'm
nervous about both of them. I hope someone here can tell me not to be
nervous about at least one choice.
Choice 1: Libc headers should always expose long long functionality
whenever those headers are compiled as C++. This makes me nervous
because it means there will be no way for users to get full standard
conforming C++ on Darwin. If libstdc++ evolves to allow turning long
long on and off at the level of an individual compilation, then a Libc
that exposes long long unconditionally won't be able to take advantage
Choice 2: Libc headers should all include c++config.h and test
_GLIBCXX_USE_LONG_LONG. This makes me nervous because c++config.h and
everything associated with them are internal to libstdc++.h, and
there's no reason to think this solution will work in future releases.
I'm leaning toward choice 1: it's inelegant but probably safe. Anyone
want to give me arguments in either direction, or suggest a third