[config] Why does BOOST_NO_INTEGRAL_INT64_T depend on BOOST_HAS_LONG_LONG?

Currently config/suffix.hpp contains the following code which seems pretty wrong to me: ---%<--- #if !defined(BOOST_HAS_LONG_LONG) && !defined(BOOST_NO_INTEGRAL_INT64_T) # define BOOST_NO_INTEGRAL_INT64_T #endif --->%--- AFAICT, the existence of a 64 bit integral type has nothing to do with support for long long types. On Tru64 for example, uint64_t is defined as unsigned long and there is no unsigned long long when the compiler operates in strict ansi mode. Shouldn't these lines just be removed? Markus

Currently config/suffix.hpp contains the following code which seems pretty wrong to me:
---%<--- #if !defined(BOOST_HAS_LONG_LONG) && !defined(BOOST_NO_INTEGRAL_INT64_T) # define BOOST_NO_INTEGRAL_INT64_T #endif --->%---
AFAICT, the existence of a 64 bit integral type has nothing to do with support for long long types. On Tru64 for example, uint64_t is defined as unsigned long and there is no unsigned long long when the compiler operates in strict ansi mode.
Shouldn't these lines just be removed?
Oh, !*>&*$! Yes, but if they are removed other stuff will break, I can pretty much guarantee that. So how long away is the release? My gut feeling at present is to fix this after 1.33 goes out, but I could go either way I guess. John.

John Maddock wrote:
Currently config/suffix.hpp contains the following code which seems pretty wrong to me:
---%<--- #if !defined(BOOST_HAS_LONG_LONG) && !defined(BOOST_NO_INTEGRAL_INT64_T) # define BOOST_NO_INTEGRAL_INT64_T #endif --->%---
AFAICT, the existence of a 64 bit integral type has nothing to do with support for long long types. On Tru64 for example, uint64_t is defined as unsigned long and there is no unsigned long long when the compiler operates in strict ansi mode.
Shouldn't these lines just be removed?
Oh, !*>&*$!
Yes, but if they are removed other stuff will break, I can pretty much guarantee that.
So how long away is the release?
My gut feeling at present is to fix this after 1.33 goes out, but I could go either way I guess.
Currently, Tru64/CXX strict mode compilation is affected by this. So why not just try it and if there are too much failures, revert it back? Markus

Currently, Tru64/CXX strict mode compilation is affected by this. So why not just try it and if there are too much failures, revert it back?
If you're willing to deal with the regressions, and the review manager agrees, then it's OK with me: but check with Doug Gregor first. John.

John Maddock wrote:
Currently, Tru64/CXX strict mode compilation is affected by this. So why not just try it and if there are too much failures, revert it back?
If you're willing to deal with the regressions, and the review manager agrees, then it's OK with me: but check with Doug Gregor first.
Doug, are you listening?

John Maddock wrote:
Currently, Tru64/CXX strict mode compilation is affected by this. So why not just try it and if there are too much failures, revert it back?
If you're willing to deal with the regressions, and the review manager agrees, then it's OK with me: but check with Doug Gregor first.
I had another idea. I'll change the code in question to: ---%<--- #if !defined(BOOST_HAS_LONG_LONG) && !defined(BOOST_NO_INTEGRAL_INT64_T) \ && !defined(__DECCXX_VER) # define BOOST_NO_INTEGRAL_INT64_T #endif --->%--- This will leave other compilers/platforms alone and works around the issue on Tru64/CXX. And of course I'll add a comment that the whole thing should be removed after the release. Is this ok with you? Markus

This will leave other compilers/platforms alone and works around the issue on Tru64/CXX. And of course I'll add a comment that the whole thing should be removed after the release.
Is this ok with you?
Sounds more sensible at this stage of the release, don't let me forget about this post release though! John.

John Maddock wrote:
This will leave other compilers/platforms alone and works around the issue on Tru64/CXX. And of course I'll add a comment that the whole thing should be removed after the release.
Sounds more sensible at this stage of the release, don't let me forget about this post release though!
Ok, commited. And I'll try to remind you to remove it after the release. :-) Markus

John Maddock wrote:
This will leave other compilers/platforms alone and works around the issue on Tru64/CXX. And of course I'll add a comment that the whole thing should be removed after the release.
Is this ok with you?
Sounds more sensible at this stage of the release, don't let me forget about this post release though!
ping :-)
participants (3)
-
John Maddock
-
Markus Schöpflin
-
Markus Schöpflin