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]
Other format: [Raw text]

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


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