Future evolution of c++config.h and _GLIBCXX_USE_LONG_LONG

[Matt Austern <austern at apple dot com>]

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

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 
choice?

			--Matt