stillwater-sc / universal / 34822571383

86%

master: 84%

Build Type

push

github

Committed by web-flow

Commit Message

fix(integer): hold operator<<'s decimal block in a type it fits (#1497)

convert_to_string(), the decimal path of operator<<, takes digits off in blocks of 10^k,
the largest power of ten a limb holds: 100, 10^4, 10^9 or 10^18. It held the block in
integer<nbits + 1, BlockType, NumberType>, where it wrapped whenever it did not fit.
integer<12, uint16_t> keeps 10^4 in 13 bits, as 1808, so every value from 1808 up
printed wrong (1808 as "10000"), for all three number types. The widths hit are the
ones narrower than the block: up to 6 bits with uint8_t limbs, 12 with uint16_t, 29
with uint32_t and 59 with uint64_t, wherever the wrapped block fell below the largest
value. In the same function, a WholeNumber value at 7, 15, 31 or 63 bits wrote "whole
number cannot be zero but division would yield 0" to stderr for every value below the
block, because integer<nbits + 1> filled a limb exactly and the one-block division
reports a zero Whole quotient.

The magnitude and the block now live in an IntegerNumber type wide enough for both, plus
a sign bit that stays clear: integer<max(nbits, bits in 10^k) + 1, BlockType,
IntegerNumber>. The magnitude is taken in the caller's own width, where negating maxneg
leaves the bit pattern of 2^(nbits-1), and is then copied limb by limb into the wider
type. Nothing in the formatter uses WholeNumber or NaturalNumber arithmetic any more, so
it no longer depends on their division, comparison or domain checks.

The new static/integer/binary/api/stream_output.cpp streams every value of every width
from 2 to 12 bits against std::to_string, for uint8_t, uint16_t, uint32_t and uint64_t
limbs and all three number types. It also samples 15 widths from 13 to 64 bits and
checks the 128-bit extremes against their decimal strings. number_types.cpp gets back
its exhaustive integer<12, uint16_t> configuration, which #1410 had dropped to avoid
this bug.

Verification:
- On the #1410 fix without this change, the test reports 48,696 wrong output... (continued)

Coverage Stats

15 of 15 new or added lines in 1 file covered. (100.0%)

9 existing lines in 2 files now uncovered.

43706 of 50942 relevant lines covered (85.8%)

7656158.65 hits per line