Thanks Chris, yes your fix looks correct to me!

yes your fix looks correct to me!

John, I was pondering this fix. You know, I did not (yet) explicitly or purposely handle the case of negative cpp_bin_float when converting to unsigned long long. Do you know what should happen for this conversion? I could program the behavior now in this PR if it's incorrect.

Ugh, always another corner case! I guess since we saturate, then zero would be the logical choice?

If they aren't there already, we should have some consistent tests (by which I mean that are run for all the integer backends) for all this. I can't remember off the top of my head where I put conversion tests (for saturation especially) - whether they are in test_arithmetic.hpp with everything else, or in the separate conversion testers.

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 94.1%. Comparing base (c433245) to head (e3b50cf).
Report is 6 commits behind head on develop.

@@            Coverage Diff            @@
##           develop    #684     +/-   ##
=========================================
+ Coverage     94.1%   94.1%   +0.1%     
=========================================
  Files          279     280      +1     
  Lines        28983   29067     +84     
=========================================
+ Hits         27257   27342     +85     
+ Misses        1726    1725      -1     

Ugh, always another corner case! I guess since we saturate, then zero would be the logical choice?

Indeed! OK, I'm working on it....

I just ran some tests on cpp_dec_float, cpp_bin_float and built-in double, such as here at godbolt.

I will make bin-float behave the same as dec-float and double. I'll go ahead and pack the code and its tests right in this PR while we are on such a roll.

Hi John (@jzmaddock) so now cpp_dec_float and cpp_bin_float behave closer to how they should and seemingly identically with each other regarding overflow/underflow of integral conversions. I added the relevant tests to the Jamfile and they are all cycling green now.

I am purposely not looking into gmp_float and mpfr_float in this particular matter at this time. But I've made a note to take a cursory glance at their behaviors. I'll also keep this and these tests in mind if we ever get back to cpp_double_fp_backend.