https://svn.boost.org/trac10/ticket/13109 <p> I found in Boost 1.63.0 on: Ubuntu 14.04.5 with g++ (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4, 64-bit Windows 10's Windows Subsystem for Linux with g++ (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609. </p> <p> code snippet: uint128_t b128 = 0xFFFFFFFFFFFFFFFFFFFFFFFFC0A800FF_cppui; unsigned long long ull( static_cast&lt;unsigned long long&gt;( b128 ) ); printf( "ull: %016llX\n", ull ); </p> <p> The output is: ull: FFFFFFFFFFFFFFFF </p> <p> Under Windows 10 and Visual Studio 2015 the output is: ull: FFFFFFFFC0A800FF </p> <p> The work around I'm using is to mask out the upper 64 bits: ull = static_cast&lt;unsigned long long&gt;(b128 &amp; 0x0FFFFFFFFFFFFFFFF); </p> <p> Thanks, Gary Visser </p> en-us /htdocs/site/boost.png https://svn.boost.org/trac10/ticket/13109 Trac 1.4.3 John Maddock Sat, 30 Dec 2017 18:17:48 GMT https://svn.boost.org/trac10/ticket/13109#comment:1 https://svn.boost.org/trac10/ticket/13109#comment:1 <ul> <li><strong>status</strong> <span class="trac-field-old">new</span> → <span class="trac-field-new">closed</span> </li> <li><strong>resolution</strong> → <span class="trac-field-new">fixed</span> </li> </ul> <p> The intended behaviour is to return the maximum value of the target type when a narrowing conversion overflows (I realise this is different behaviour to most built in integer types, but then you're into undefined behaviour). </p> <p> This patch: <a class="ext-link" href="https://github.com/boostorg/multiprecision/commit/b35f1c8f613db66ad80ce260f94b7027814ede71"><span class="icon">​</span>https://github.com/boostorg/multiprecision/commit/b35f1c8f613db66ad80ce260f94b7027814ede71</a> enforces uniform behaviour across all backend integer types. </p> <p> In future, if you really want just the low order N bits, then you will need to mask these out - the same is true of built in integers actually if you want to avoid code-sanitizer errors (cland usan etc). </p> Ticket