Project

General

Profile

Actions

Bug #5224

closed

snprintf rounding under [default] FE_TONEAREST

Added by Richard PALO over 6 years ago. Updated over 6 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
lib - userland libraries
Start date:
2014-10-29
Due date:
% Done:

100%

Estimated time:
(Total: 0.00 h)
Difficulty:
Hard
Tags:
needs-triage
Gerrit CR:

Description

In the attached test program, the double value 1.0/3.0 is output with the default (FE_TONEAREST)
as well as the other modes.
It appears that there are anomalies, at least involving 'f' precision 17 and 18
(for the first test series FE_TONEAREST), which seemingly should output
"f precision 17 => +0.3333333333333333*1*" and
"f precision 18 => +0.33333333333333331*5*" respectfully.

(For the 'e' precision, it appears to affect precision 16 and 17.)

FLT_ROUNDS = 1, fegetround()=0
FLT_EVAL_METHOD = 2
DBL_MANT_DIG = 53
DECIMAL_DIG = 21
DBL_DIG = 15
fesetround(FE_TONEAREST)
e precision 15 => +3.333333333333333e-01
f precision 15 => +0.333333333333333
e precision 16 => +3.3333333333333332e-01
f precision 16 => +0.3333333333333333
e precision 17 => +3.33333333333333312e-01
f precision 17 => +0.33333333333333332
e precision 18 => +3.333333333333333148e-01
f precision 18 => +0.333333333333333312
e precision 19 => +3.3333333333333331483e-01
f precision 19 => +0.3333333333333333148
e precision 20 => +3.33333333333333314830e-01
f precision 20 => +0.33333333333333331483
e precision 21 => +3.333333333333333148296e-01
f precision 21 => +0.333333333333333314830
e precision 22 => +3.3333333333333331482962e-01
f precision 22 => +0.3333333333333333148296
fesetround(FE_DOWNWARD)
e precision 15 => +3.333333333333333e-01
f precision 15 => +0.333333333333333
e precision 16 => +3.3333333333333331e-01
f precision 16 => +0.3333333333333333
e precision 17 => +3.33333333333333314e-01
f precision 17 => +0.33333333333333331
e precision 18 => +3.333333333333333148e-01
f precision 18 => +0.333333333333333314
e precision 19 => +3.3333333333333331482e-01
f precision 19 => +0.3333333333333333148
e precision 20 => +3.33333333333333314829e-01
f precision 20 => +0.33333333333333331482
e precision 21 => +3.333333333333333148296e-01
f precision 21 => +0.333333333333333314829
e precision 22 => +3.3333333333333331482961e-01
f precision 22 => +0.3333333333333333148296
fesetround(FE_UPWARD)
e precision 15 => +3.333333333333334e-01
f precision 15 => +0.333333333333334
e precision 16 => +3.3333333333333332e-01
f precision 16 => +0.3333333333333334
e precision 17 => +3.33333333333333315e-01
f precision 17 => +0.33333333333333332
e precision 18 => +3.333333333333333149e-01
f precision 18 => +0.333333333333333315
e precision 19 => +3.3333333333333331483e-01
f precision 19 => +0.3333333333333333149
e precision 20 => +3.33333333333333314830e-01
f precision 20 => +0.33333333333333331483
e precision 21 => +3.333333333333333148297e-01
f precision 21 => +0.333333333333333314830
e precision 22 => +3.3333333333333331482962e-01
f precision 22 => +0.3333333333333333148297
fesetround(FE_TOWARDZERO)
e precision 15 => +3.333333333333333e-01
f precision 15 => +0.333333333333333
e precision 16 => +3.3333333333333331e-01
f precision 16 => +0.3333333333333333
e precision 17 => +3.33333333333333314e-01
f precision 17 => +0.33333333333333331
e precision 18 => +3.333333333333333148e-01
f precision 18 => +0.333333333333333314
e precision 19 => +3.3333333333333331482e-01
f precision 19 => +0.3333333333333333148
e precision 20 => +3.33333333333333314829e-01
f precision 20 => +0.33333333333333331482
e precision 21 => +3.333333333333333148296e-01
f precision 21 => +0.333333333333333314829
e precision 22 => +3.3333333333333331482961e-01
f precision 22 => +0.3333333333333333148296

According to ISO C 7.19.6.2 n°13

For e, E, f, F, g, and G conversions, if the number of significant decimal digits is at most
DECIMAL_DIG, then the result should be correctly rounded. 249) If the number of
significant decimal digits is more than DECIMAL_DIG but the source value is exactly
representable with DECIMAL_DIG digits, then the result should be an exact
representation with trailing zeros. Otherwise, the source value is bounded by two
adjacent decimal strings L < U, both having DECIMAL_DIG significant digits; the value
of the resultant decimal string D should satisfy L ≤ D ≤ U, with the extra stipulation that
the error should have a correct sign for the current rounding direction.

249) For binary-to-decimal conversion, the result format’s values are the numbers representable
with the given format specifier. The number of significant digits is determined by the format
specifier, and in the case of fixed-point conversion by the source value as well.

Interestingly, according to a source, this may be fixed in Or*cle Solaris 11.x...
It would be nice to check.


Files

cflt2.c (1.32 KB) cflt2.c Richard PALO, 2014-10-10 04:13 PM
cflt3.truss.oi (7.84 KB) cflt3.truss.oi snprintf trace extract working on oi_151a9 Richard PALO, 2014-10-19 09:07 AM
cflt3.truss (4.35 KB) cflt3.truss snprintf trace failing on omnios Richard PALO, 2014-10-19 09:07 AM
tmul.c (1.06 KB) tmul.c Richard PALO, 2014-10-19 01:15 PM
cflt4.c (1.12 KB) cflt4.c Richard PALO, 2014-10-22 06:33 AM

Subtasks 1 (0 open1 closed)

Feature #5276: Add Richard PALO's fpround test.ClosedDan McDonald2014-10-29

Actions
Actions

Also available in: Atom PDF