View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000346 | 1003.1(2008)/Issue 7 | System Interfaces | public | 2010-11-04 20:41 | 2013-04-16 13:06 |
| Reporter | eblake | Assigned To | ajosey | ||
| Priority | normal | Severity | Objection | Type | Error |
| Status | Closed | Resolution | Accepted As Marked | ||
| Name | Eric Blake | ||||
| Organization | Red Hat | ||||
| User Reference | ebb.ceil | ||||
| Section | ceil | ||||
| Page Number | 645 | ||||
| Line Number | 21865 | ||||
| Interp Status | Approved | ||||
| Final Accepted Text | See 0000346:0000649 | ||||
| Summary | 0000346: ceil and floor cannot fail | ||||
| Description | From the glibc ceil.3 man page: SUSv2 and POSIX.1-2001 contain text about overflow (which might set errno to ERANGE, or raise an FE_OVERFLOW exception). In practice, the result cannot overflow on any current machine, so this error-handling stuff is just nonsense. (More precisely, overflow can happen only when the maximum value of the exponent is smaller than the number of man‐ tissa bits. For the IEEE-754 standard 32-bit and 64-bit floating-point numbers the maximum value of the exponent is 128 (respectively, 1024), and the number of mantissa bits is 24 (respectively, 53).) In particular, if the MX option is supported, ceil and floor cannot fail, since all IEC 60559 floating-point formats have larger exponent ranges than mantissa widths. But even without the MX option, no implementation to date has ever had a floating point type that could overflow. Therefore, it is not worth keeping the text about potential errors, just for the sake of a future weirdnix. | ||||
| Desired Action | Replace lines 21865-21868 (ceil DESCRIPTION) and lines 28567-28570 (floor DESCRIPTION): An application wishing to check for error situations should set errno to zero and call feclearexcept(FE_ALL_EXCEPT) before calling these functions. On return, if errno is non-zero or fetestexcept(FE_INVALID | FE_DIVBYZERO | FE_OVERFLOW | FE_UNDERFLOW) is non-zero, an error has occurred. with: <MX>If IEC 60559 Floating-Point is supported, this function shall not fail. Otherwise,</MX> behavior is unspecified if overflow occurs. Delete lines 21874-21875 (ceil RETURN VALUE) and lines 28577-28579 (floor RETURN VALUE): If the correct value would cause overflow, a range error shall occur and ceil( ), ceilf( ), and ceill( ) [floor( ), floorf( ), and floorl( )] shall return the value of the macro HUGE_VAL, HUGE_VALF, and HUGE_VALL, [-HUGE_VAL, -HUGE_VALF, and -HUGE_VALL] respectively. Replace lines 21877-21882 (ceil ERRORS) and lines 28581-28586 (floor ERRORS): These functions shall fail if: <XSI>Range Error If the integer expression (math_errhandling & MATH_ERRNO) is non-zero, then errno shall be set to [ERANGE]. If the integer expression (math_errhandling & MATH_ERREXCEPT) is non-zero, then the overflow floating-point exception shall be raised.</XSI> with: No errors are defined. At lines 21889-21892 (ceil APPLICATION USAGE) and lines 28593-28596 (floor APPLICATION USAGE), replace: The ceil( ) [floor( )] function can only overflow when the floating-point representation has DBL_MANT_DIG > DBL_MAX_EXP. On error, the expressions (math_errhandling & MATH_ERRNO) and (math_errhandling & MATH_ERREXCEPT) are independent of each other, but at least one of them must be non-zero. with: The ceil( ) [floor( )] function can only overflow when the floating-point representation has DBL_MANT_DIG > DBL_MAX_EXP. This is not possible with IEC 60559 floating-point formats, and since there is no known hardware with an alternative floating-point format that fits this description, behavior on overflow is left unspecified. | ||||
| Tags | c99, tc1-2008 | ||||
|
|
round() also cannot fail, for the same reasons, and should likewise be included in the resulting cleanup (trunc() is a related function, but it is already documented as being unable to fail). In fact, it may even be appropriate to make a more sweeping change, and explicitly exclude any weirdnix systems from ever introducing a new floating point type that introduces pitfalls with more mantissa bits than exponent range, with this additional change: At lines 8196-8198 (XBD <float.h>), change: FLT_MAX_EXP DBL_MAX_EXP LDBL_MAX_EXP to: FLT_MAX_EXP <CX>FLT_MANT_DIG</CX> DBL_MAX_EXP <CX>DBL_MANT_DIG</CX> LDBL_MAX_EXP <CX>LDBL_MANT_DIG</CX> That is, we would be requiring, as a tightening of the C standard, that all POSIX floating-point representations have the quality that the exponent range is at least as large as the number of mantissa digits. |
|
|
As well as round(), the same applies to rint() and nearbyint(). If we decide we want to require that xxx_MANT_DIG <= xxx_MAX_EXP, I would prefer an explicit statement about that, rather than listing xxx_MANT_DIG as a minimum "value" for xxx_MAX_EXP. (All the other minimum values are fixed numeric values.) |
|
|
According to: https://secure.wikimedia.org/wikipedia/en/wiki/IBM_Floating_Point_Architecture The IBM/370 architecture supports an extended-precision 128-bit format with 7 bits reserved for exponent and 112 bits reserved for mantissa. This would imply that the maximum exponent range is 2**64, which is less than the number of mantissa bits, so the largest representable finite value of this type would be non-integral and overflow would be relevant. However, I am not sure whether this data type representation is used for the 'long double' type of a conforming implementation on that hardware, or whether all conforming implementations for that hardware instead emulate a data type closer to IEC 60559 floating point formats, or even treat 'double' and 'long double' both as double-precision 64-bit formats in a conforming environment with no 128-bit format in that setup. While it is clear that <MX> implementations cannot overflow, given the constraints of IEC 60559 formats, we need a determination on whether the IBM/370 quad-precision is used before we can decide whether to make a blanket <CX> requirement that LDBL_MAX must be integral (the exponent range must be larger than the mantissa bits), or whether we must continue to support overflow wording for this unusual floating point format. |
|
|
Here is something more official from IBM....this is from Joshua Knight, z/OS UNIX System Services: ============ The floating point representation discussed here: https://secure.wikimedia.org/wikipedia/en/wiki/IBM_Floating_Point_Architecture dates to the 1960s. Of course the current zArchitecture http://en.wikipedia.org/wiki/Z/Architecture still supports that floating point representation but it also supports IEEE floating point, since the late 1990's http://en.wikipedia.org/wiki/IBM_Floating_Point_Architecture While I do not think 370 hexadecimal floating point is a major issue at this time, the following statement by Eric Blake "This would imply that the maximum exponent range is 2**64 ..." Is not correct. In 370 hexadecimal floating point format, the exponent is a power of 16 so it is not the case that "the largest representable finite value of this type would be non-integral" Just to set the record straight. ====================== |
|
|
Since the group was unable to find a counterexample of a hardware real-floating type that could overflow on ceil(), the group consensus was to tighten the standard regarding permissible floating-point characteristics as an extension to ISO C, and then make appropriate simplifications in function descriptions. Additionally, while preparing these changes, it was noted that rint() is required to match ceil() or floor() in certain circumstances, but that rint() documents the possibility of an inexact exception while ceil() and floor() do not. The following changes address all of these points (remember, all floating point operations are allowed to raise an inexact exception unless explicitly required not to [line 8054], as is the case with nearbyint(), so documenting inexact exceptions only in application usage is appropriate). At line 8198 [XBD <float.h> DESCRIPTION], add a paragraph within the *_MAX_EXP bullet: <CX>Additionally, FLT_MAX_EXP shall be at least as large as FLT_MANT_DIG, DBL_MAX_EXP shall be at least as large as DBL_MANT_DIG, and LDBL_MAX_EXP shall be at least as large as LDBL_MANT_DIG; which has the effect that FLT_MAX, DBL_MAX, and LDBL_MAX are integral.</CX> At line 8224 [XBD <float.h> RATIONALE], change "None." to: All known hardware floating-point formats satisfy the property that the exponent range is larger than the number of mantissa digits. The ISO C standard permits a floating-point format where this property is not true, such that the largest finite value would not be integral; however, it is unlikely that there will ever be hardware support for such a floating point format, and it introduces boundary cases that portable programs should not have to be concerned with (for example, a non-integral DBL_MAX means that ceil() would have to worry about overflow). Therefore, this standard imposes an additional requirement that the largest representable finite value is integral. For [XSH ceil], delete lines 21865-21868 (DESCRIPTION), lines 21874-21875 (RETURN VALUE), replace lines 21877-21882 (ERRORS) with: No errors are defined. at line 21870 (RETURN VALUE), add "<MX>The result shall have the same sign as x.</MX>". at line 21886 (APPLICATION USAGE), change "an int or long" to "an intmax_t", and replace lines 21889-21892 (APPLICATION USAGE) with: These functions may raise the inexact floating-point exception if the result differs in value from the argument. For [XSH floor], delete lines 28567-28570 (DESCRIPTION), lines 28577-28579 (RETURN VALUE), replace lines 28581-28586 (ERRORS) with: No errors are defined. at line 28572 (RETURN VALUE), add "<MX>The result shall have the same sign as x.</MX>". at line 28590 (APPLICATION USAGE), change "an int or long" to "an intmax_t", and replace lines 28593-28596 (APPLICATION USAGE) with: These functions may raise the inexact floating-point exception if the result differs in value from the argument. For [XSH nearbyint], delete lines 44682-44685 (DESCRIPTION), lines 44691-44693 (RETURN VALUE), replace lines 44695-44700 (ERRORS) with: No errors are defined. at line 44867 (RETURN VALUE), add "<MX>The result shall have the same sign as x.</MX>". and replace lines 44704-44705 (APPLICATION USAGE) with: The integral value returned by these functions need not be expressible as an intmax_t. The return value should be tested before assigning it to an integer type to avoid the undefined results of an integer overflow. For [XSH rint], add to the paragraph at line 57201: If the current rounding mode rounds towards zero, then rint() shall be equivalent to trunc(). <MX>If the current rounding mode rounds towards nearest, then rint() differs from round() in that halfway cases are rounded to even rather than away from zero.</MX> delete lines 57214-57216 (RETURN VALUE), replace lines 57218-57223 (ERRORS) with: No errors are defined. at line 57211 (RETURN VALUE), add "<MX>The result shall have the same sign as x.</MX>". and replace lines 57227-57228 (APPLICATION USAGE) with: The integral value returned by these functions need not be expressible as an intmax_t. The return value should be tested before assigning it to an integer type to avoid the undefined results of an integer overflow. For [XSH round], delete lines 57367-57370 (DESCRIPTION), lines 57375-57377 (RETURN VALUE), replace lines 57379-57384 (ERRORS) with: No errors are defined. at line 57372 (RETURN VALUE), add "<MX>The result shall have the same sign as x.</MX>". and replace lines 57388-57389 (APPLICATION USAGE) with: The integral value returned by these functions need not be expressible as an intmax_t. The return value should be tested before assigning it to an integer type to avoid the undefined results of an integer overflow. These functions may raise the inexact floating-point exception if the result differs in value from the argument. For [XSH trunc], at line 67539 (RETURN VALUE), add "<MX>The result shall have the same sign as x.</MX>". and at line 67547 (APPLICATION USAGE), replace "None." with: The integral value returned by these functions need not be expressible as an intmax_t. The return value should be tested before assigning it to an integer type to avoid the undefined results of an integer overflow. These functions may raise the inexact floating-point exception if the result differs in value from the argument. |
|
|
Interpretation response ------------------------ The standard states that checks for overflow should be made, even though they cannot happen , and conforming implementations must conform to this. However, concerns have been raised about this which are being referred to the sponsor. Rationale: ------------- See Notes above Notes to the Editor (not part of this interpretation): ------------------------------------------------------ See 0000346:0000633 |
|
|
Interpretation proposed 15 Mar 2011 for final 30 day review |
|
|
The interpretation is now approved. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2010-11-04 20:41 | eblake | New Issue | |
| 2010-11-04 20:41 | eblake | Status | New => Under Review |
| 2010-11-04 20:41 | eblake | Assigned To | => ajosey |
| 2010-11-04 20:41 | eblake | Name | => Eric Blake |
| 2010-11-04 20:41 | eblake | Organization | => Red Hat |
| 2010-11-04 20:41 | eblake | User Reference | => ebb.ceil |
| 2010-11-04 20:41 | eblake | Section | => ceil |
| 2010-11-04 20:41 | eblake | Page Number | => 645 |
| 2010-11-04 20:41 | eblake | Line Number | => 21865 |
| 2010-11-04 20:41 | eblake | Interp Status | => --- |
| 2010-11-04 23:01 | eblake | Note Added: 0000600 | |
| 2010-11-05 10:34 | geoffclare | Note Added: 0000602 | |
| 2010-11-18 16:18 | nick | Tag Attached: c99 | |
| 2010-11-18 16:33 | eblake | Note Added: 0000617 | |
| 2010-11-19 14:18 | msbrown | Note Added: 0000620 | |
| 2010-12-03 18:05 | eblake | Note Added: 0000633 | |
| 2010-12-03 18:08 | eblake | Note Edited: 0000633 | |
| 2010-12-09 17:21 | eblake | Note Edited: 0000633 | |
| 2010-12-09 17:25 | eblake | Note Edited: 0000633 | |
| 2011-01-13 17:18 | eblake | Note Edited: 0000633 | |
| 2011-01-13 17:24 | nick | Interp Status | --- => Pending |
| 2011-01-13 17:24 | nick | Note Added: 0000649 | |
| 2011-01-13 17:24 | nick | Status | Under Review => Interpretation Required |
| 2011-01-13 17:24 | nick | Resolution | Open => Accepted As Marked |
| 2011-01-13 17:25 | nick | Final Accepted Text | => See 0000346:0000649 |
| 2011-01-13 17:26 | nick | Note Edited: 0000649 | |
| 2011-01-13 17:27 | nick | Tag Attached: tc1-2008 | |
| 2011-03-15 14:46 | ajosey | Interp Status | Pending => Proposed |
| 2011-03-15 14:46 | ajosey | Note Added: 0000707 | |
| 2011-04-26 15:11 | ajosey | Interp Status | Proposed => Approved |
| 2011-04-26 15:11 | ajosey | Note Added: 0000770 | |
| 2013-04-16 13:06 | ajosey | Status | Interpretation Required => Closed |
