[Cfp-interest] (SC22WG14.14281) Can DECIMAL_DIG be larger than necessary?

[Jim Thomas]

What is the harm in allowing DECIMAL_DIG to be wider than the give formula? Using the macro to determine the number of digits to print might result in more digits than would be necessary or desirable (for standard floating types). Even without Part 3, the macro couldn’t be used in reproducible programs because it depends on long double.

 Maybe a better option would be to have the macro definition depend on whether __STDC_WANT_IEC_60559_TYPES_EXT__ is defined.

Jim Thomas

> On Jun 16, 2016, at 3:13 PM, Joseph Myers <joseph at codesourcery.com> wrote:
> 
> C11 defines DECIMAL_DIG as "number of decimal digits, n, such that any 
> floating-point number in the widest supported floating type with p_max 
> radix b digits can be rounded to a floating-point number with n decimal 
> digits and back again without change to the value," and then gives a 
> formula.
> 
> Is it OK for the value of DECIMAL_DIG to be larger than given by the 
> formula?  Such a value would still seem to meet the textual description, 
> though being suboptimal.
> 
> This is an issue for implementing TS 18661-3 when that involves types 
> wider than long double.  In C11, "real floating type" means float, double 
> or long double (6.2.5#10) (and then those types plus the three complex 
> types are defined to be the floating types).  TS 18661-3 is supposed to be 
> compatible with C11, so that an implementation can conform to both 
> simultaneously.  The definition of DECIMAL_DIG in TS 18661-3 covers all 
> supported floating types and non-arithmetic encodings.  And that's not 
> conditional on __STDC_WANT_IEC_60559_TYPES_EXT__.  So in an implementation 
> of TS 18661-3 that supports _Float128, DECIMAL_DIG must be big enough for 
> _Float128, even if __STDC_WANT_IEC_60559_TYPES_EXT__ is not defined when 
> <float.h> is included.  And that's only compatible with C11 (if long 
> double is narrower than _Float128) if C11 allows DECIMAL_DIG to be larger 
> than given by the formula.
> 
> -- 
> Joseph S. Myers
> joseph at codesourcery.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20160621/0f9199e2/attachment-0001.html