summaryrefslogtreecommitdiff
path: root/README
diff options
context:
space:
mode:
authorRich Felker <dalias@aerifal.cx>2026-05-21 09:37:18 -0400
committerRich Felker <dalias@aerifal.cx>2026-05-21 09:37:18 -0400
commit50979c5bc89a7b02023e5c0a5ea1ca4da8616a91 (patch)
treeaad36c9e64666005aa594fd71430d6008bf22b7c /README
parentbf96b52a4429eeeb60e6c961c8687e52d90c5fa1 (diff)
downloadmusl-50979c5bc89a7b02023e5c0a5ea1ca4da8616a91.tar.gz
fix rounding of hex floats in strtod/scanf on ld64 and ld128 archs
the expression LDBL_MANT_DIG/4+1 was intended to represent the number of hex digits which can be significant, after which all that matters to the result, regardless of rounding mode, is whether any part of the tail is nonzero. however, the expression LDBL_MANT_DIG/4 is only exact for ld80 archs. for ld64 and ld128, the truncation of the remainder caused one too few digits to be processed, producing incorrect rounding. for ld128 archs, only strtold and scanf's %La conversion specifier were affected; doubles and floats still had plenty of trailing digits to yield a correct final rounding. but for ld64 archs, the number of digits processed were insufficient for double, and could affect any code using strtod or scanf's %a. for ld64 archs, 0x1.111111111111281 produces an incorrect rounding down, and 0x1.11111111111111 produces an incorrect rounding up. for ld128 archs, the inputs 0x1.111111111111111111111111111281 and 0x1.11111111111111111111111111111 behave respectively. rounding up in the expression for the number of hex digits needed produces correct results.
Diffstat (limited to 'README')
0 files changed, 0 insertions, 0 deletions