View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000803 | 1003.1(2013)/Issue7+TC1 | Base Definitions and Headers | public | 2013-11-21 23:26 | 2014-02-06 16:49 |
| Reporter | shware_systems | Assigned To | |||
| Priority | normal | Severity | Objection | Type | Error |
| Status | Closed | Resolution | Rejected | ||
| Name | Mark Ziegast | ||||
| Organization | |||||
| User Reference | |||||
| Section | XBD <fenv.h> | ||||
| Page Number | 244 | ||||
| Line Number | 8067-79 | ||||
| Interp Status | --- | ||||
| Final Accepted Text | |||||
| Summary | 0000803: Interfaces are 'shall be' when should be 'may be' | ||||
| Description | The interfaces that depend on whether the header includes various FE_* macro definitions are listed as always required. This conflicts with the C standard. If they are supposed to be required, the text for the constants should be 'shall be' rather than 'may be'. Proposed is alternate for keeping C standard compatibility. | ||||
| Desired Action | Replace Lines 8067-79 with: The following shall be declared as functions and may also be defined as macros. Function prototypes shall be provided. int fegetenv(fenv_t *); int feholdexcept(fenv_t *); int fesetenv(const fenv_t *); int feupdateenv(const fenv_t *); The following shall be declared as functions and may also be defined as macros when any of the macros: FE_DIVBYZERO, FE_INEXACT, FE_INVALID, FE_OVERFLOW, FE_UNDERFLOW are defined as above. Function prototypes shall be provided when declared. int feclearexcept(int); int fegetexceptflag(fexcept_t *, int); int feraiseexcept(int); int fesetexceptflag(const fexcept_t *, int); int fetestexcept(int); The following shall be declared as functions and may also be defined as macros when any of the macros: FE_DOWNWARD, FE_TONEAREST, FE_TOWARDZERO, FE_UPWARD are defined as above. Function prototypes shall be provided when declared. int fegetround(void); int fesetround(int); | ||||
| Tags | C11, c99 | ||||
|
|
You are misinterpreting the C standard. There is no conflict between C99 and POSIX here. |
|
|
c99tc3, Sect 7.6 5 Each of the macros FE_DIVBYZERO FE_INEXACT FE_INVALID FE_OVERFLOW FE_UNDERFLOW ~is defined if and only if the implementation supports~ the floating-point exception by means of the functions in 7.6.2.(181) 7 Each of the macros FE_DOWNWARD FE_TONEAREST FE_TOWARDZERO FE_UPWARD ~is defined if and only if the implementation supports~ getting and setting the represented rounding direction by means of the fegetround and fesetround functions. If none of those exceptions or rounding modes are supported those functions aren't required to be provided and those interfaces need not appear in the header, otherwise at least one of those constants need always be defined so the interfaces have suitable inputs. An application tests if the FE_* is defined to see whether the desired interface is supported is how it seems to me. If it's not defined it has to presume that the interfaces aren't present so uses them in code protected by an #ifdef FE_* block. For IEC 60559 support those are all required, but that's optional on a system that does FPU emulations or has an incompatible FPU. The language is wonky somewhere. |
|
|
Nothing in what you quoted says that the functions are optional. Each macro is optionally defined, depending on whether that particular exception or rounding mode is supported. The functions themselves are mandatory. C90 and C99 had no optional functions. C11 is the first revision of the C standard to have optional functions. |
|
|
Ok, I see what you're saying. I was looking at it as what's nominally portable, and construing it that way I think would be. With that, though, it seems the corollary is for those interfaces only implementation defined constants differing from those FE_* ones may be the only ones provided and it's still conforming. That doesn't look portable to me. For application startup rounding mode at least requiring one of those would be, and may support the others, but that would be CX. For exceptions an app could consider it as non-stop is the only exception mode supported, or SIG_FPE raised with a non-integer (FPE_INT* or FPE_FLTSUB) exception code can only abort if feholdexcept() can't set a non-stop mode. However, I think something more about what environment a portable application can rely on being present is required as the C language is specific to particular implementations that it might consider conforming. If that should be a separate Bug report, fine, we can close this one after that's opened. |
|
|
The functionality described on the fenv.h reference page is aligned with the ISO C standard. Any conflict between the requirements described there and the ISO C standard is unintentional. This volume of POSIX.1-2008 defers to the ISO C standard. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2013-11-21 23:26 | shware_systems | New Issue | |
| 2013-11-21 23:26 | shware_systems | Name | => Mark Ziegast |
| 2013-11-21 23:26 | shware_systems | Section | => XBD <fenv.h> |
| 2013-11-21 23:26 | shware_systems | Page Number | => 244 |
| 2013-11-21 23:26 | shware_systems | Line Number | => 8067-79 |
| 2013-11-22 12:32 | geoffclare | Note Added: 0002013 | |
| 2013-11-22 16:23 | shware_systems | Note Added: 0002014 | |
| 2013-11-22 16:33 | shware_systems | Note Edited: 0002014 | |
| 2013-11-22 17:32 | geoffclare | Note Added: 0002015 | |
| 2013-11-22 20:51 | shware_systems | Note Added: 0002016 | |
| 2014-02-06 16:35 | nick | Tag Attached: C11 | |
| 2014-02-06 16:35 | nick | Tag Attached: c99 | |
| 2014-02-06 16:49 | nick | Interp Status | => --- |
| 2014-02-06 16:49 | nick | Note Added: 0002124 | |
| 2014-02-06 16:49 | nick | Status | New => Closed |
| 2014-02-06 16:49 | nick | Resolution | Open => Rejected |
