[repost] integer tests not working on 64 bit platforms
The following is a repost of a message I mailed in last september. The problem with the test is still present in the current CVS. Would anyone mind if I just go for the first fix proposed? Markus ---%<--- Currently the integer tests report an error on 64 bit platforms, as can be seen on http://tinyurl.com/7aoe9 The following code in integer_test.cpp causes the problem: PRIVATE_FIT_TESTS( int_t, least, long, LONG_MAX ); PRIVATE_FIT_TESTS( int_t, fast, long, LONG_MAX ); PRIVATE_FIT_TESTS( uint_t, least, unsigned long, ULONG_MAX ); PRIVATE_FIT_TESTS( uint_t, fast, unsigned long, ULONG_MAX ); The first line expands to: do { long v = LONG_MAX ; PRIVATE_FIT_TEST(int_t, 32, least, v); v >>= 1; PRIVATE_FIT_TEST(int_t, 31, least, v); v >>= 1; ... } which becomes: do { long v = LONG_MAX ; BOOST_TEST( int_t < 32 > :: least ( v ) == v ); v >>= 1; BOOST_TEST( int_t < 31 > :: least ( v ) == v ); v >>= 1; ... } which of course alway fails on 64 bit platforms because LONG_MAX is a 64 bit number. A possible fix would be to start the test with 64 bit and not 32 on 64 bit platforms. But how can 64 bit platforms be detected? Probably with #if (LONG_MAX > INT_MAX) ... #endif or something like this. Another fix (which ignores 64 bit values alltogether) would be to change the lines above to not use long and LONG_MAX but int and INT_MAX. Opinions, anyone? Markus --->%---
which of course alway fails on 64 bit platforms because LONG_MAX is a 64 bit number.
A possible fix would be to start the test with 64 bit and not 32 on 64 bit platforms. But how can 64 bit platforms be detected? Probably with #if (LONG_MAX > INT_MAX) ... #endif or something like this.
Another fix (which ignores 64 bit values alltogether) would be to change the lines above to not use long and LONG_MAX but int and INT_MAX.
Opinions, anyone?
Tricky, but looking at the intent of the tests, it seems like we should start with the largest number that will fit in a 32-bit type: so maybe we should change LONG_MAX to 0x7FFFFFFFL and ULONG_MAX to 0xFFFFFFFFL. As you say the alternative is to revamp the tests to start testing from a 64-bit type when LONG_MAX > 0x7FFFFFFFL. I'd say go with whichever you have the time for ;-) John.
At Wednesday 2005-04-20 03:16, you wrote:
which of course alway fails on 64 bit platforms because LONG_MAX is a 64 bit number.
A possible fix would be to start the test with 64 bit and not 32 on 64 bit platforms. But how can 64 bit platforms be detected? Probably with #if (LONG_MAX > INT_MAX) ... #endif or something like this.
Another fix (which ignores 64 bit values alltogether) would be to change the lines above to not use long and LONG_MAX but int and INT_MAX.
Opinions, anyone?
Tricky, but looking at the intent of the tests, it seems like we should start with the largest number that will fit in a 32-bit type: so maybe we should change LONG_MAX to 0x7FFFFFFFL and ULONG_MAX to 0xFFFFFFFFL. As you say the alternative is to revamp the tests to start testing from a 64-bit type when LONG_MAX > 0x7FFFFFFFL.
I'd say go with whichever you have the time for ;-)
Am I missing something here? Isn't this was numeric_limits<> was put in the language for?
John.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
On Apr 20, 2005, at 3:06 AM, Markus Schöpflin wrote:
The following is a repost of a message I mailed in last september. The problem with the test is still present in the current CVS. Would anyone mind if I just go for the first fix proposed?
The first fix looks reasonable to me. I say go ahead. Doug
participants (4)
-
Douglas Gregor -
John Maddock -
Markus Schöpflin -
Victor A. Wagner Jr.