Re: [boost] Regression test relying on undefined compiler behavior (c++11)

Subject: Re: [boost] Regression test relying on undefined compiler behavior (c++11)
From: Ben Pope (benpope81_at_[hidden])
Date: 2014-04-23 22:37:03

On Thursday, April 24, 2014 01:59 AM, Chris Cooper wrote:
> libs/utility/numeric_traits_test.cpp generates values complement_traits<Number>::min using a clever recursive template, but that template relies on left-shifting a negative value, and according to the C++11 standard that’s a no-no (“the behavior is undefined”) which means it’s not a constant expression, which means it can’t be calculated at compile time, which means the BOOST_STATIC_ASSERT in line 332 won’t compile, saying “static_assert expression is not an integral constant expression” (I’m using clang++).
>
> See discussion here: http://stackoverflow.com/questions/23250651/strange-behavior-with-c-recursive-templates-when-c11-is-enabled
>
> In addition, it looks like the existing code also relies on the compiler filling the vacated bits with one’s, which I don’t think is what actually happens.
>
> The solution I’ve come up with, is to do the shifting using unsigned values, thus avoiding the compiler no-no, and then putting the result back in the specified type.  In other words, replacing line 73
>
>
> BOOST_STATIC_CONSTANT(Number, min = Number(Number(prev::min) << CHAR_BIT));
>
> With
>
>
> BOOST_STATIC_CONSTANT(Number, min = boost::detail::is_signed<Number>::value ? (Number)(((unsigned long)(prev::min) << 8) | 0x00FF) : Number(Number(prev::min) << CHAR_BIT) );
>
> I’m using constants ‘8’ and ‘0x00FF’ rather than CHAR_BIT since the code would get really ugly if CHAR_BIT != 8.
>
> Thoughts?

https://github.com/boostorg/utility/pull/4

http://thread.gmane.org/gmane.comp.lib.boost.devel/250143

Ben