[Cfp-interest 2790] action item about TS-5, pragma prefixes

[Jim Thomas]

>     All: TS part 5: Consider what to do for issue 3 (which headers contain which pragmas) as per the spreadsheet (current vs alternative 1).
> [Cfp-interest 2755] pragma spreadsheet  <http://mailman.oakapple.net/pipermail/cfp-interest/2023-May/002769.html>  Jim Thomas



Observations about standard pragma prefixes and headers, and a suggestion …

1. C99 pragmas

FP_CONTRACT
FENV_ACCESS
CX_LIMITED_RANGE

are established. The prefixes reflect what the pragmas control. The association of FP_CONTRACT with math.h is questionable, since the pragma is about expression evaluation, not math functions.

2. C23 pragmas

FENV_ROUND
FENV_DEC_ROUND

seem reasonably prefixed because the floating-point environment has been about managing rounding modes and flags. The pragmas’ constant rounding modes aren’t actually part of the dynamic floating-point environment, but they override the dynamic rounding modes.

3. The current TS-5 evaluation method and optimization pragmas

FENV_FLT_EVAL_METHOD
FENV_DEC_EVAL_METHOD
FENV_ALLOW_VALUE_CHANGING_OPTIMIZATION
FENV_ALLOW_ASSOCIATIVE_LAW
FENV_ALLOW_DISTRIBUTIVE_LAW
FENV_ALLOW_MULTIPLY_BY_RECIPROCAL
FENV_ALLOW_ZERO_SUBNORMAL
FENV_ALLOW_CONTRACT_FMA
FENV_CONTRACT_OPERATION_CONVERSION
FENV_CONTRACT

are similar to the C99 pragma FP_CONTRACT in that they control the semantics of floating-point expressions. Although a few of these pragmas might be implemented with help from the floating-point environment, this should not concern the user. FP_ would be a more descriptive prefix.

4. The TS-5 pragma

FENV_REPRODUCIBLE 

relates to the floating-point environment and floating-point expressions. The greater potential interest is probably in floating-point expressions. “FP” (vs “FENV”) is more suggestive of floating point in general. FP_ seems to be a slightly better prefix here.

5. The TS-5 pragma

FENV_EXCEPT

is about exception handling. The FENV_ prefix is appropriate.

6. The current TS-5 use of FENV_ for the pragmas controlling floating-point expressions expands the concept of the floating-point environment to include translation-time modes. This should be acknowledged in the TS if the prefixes remain unchanged.

7. Changing the prefixes for the pragmas controlling floating-point expressions to FP_ should entail moving the pragmas to math.h, thus expanding the concept of math.h beyond math functions. Current math.h is not exclusively about math functions as it contains FP_CONTRACT and _t types.

8. The meaning of a pragma being in a header is unclear. 

9. In the future, WG14 might consider disassociating standard pragmas from headers.

10. The TS-5 pragmas with their current prefixes and associated headers have been published (version 1, 2016). However, this is a TS, not a standard. The pragmas were not introduced to codify existing implementations. I suspect changing prefixes and headers would not greatly harm implementations or users.


Suggestion for TS-5 version 2: 

Delete FENV_CONTRACT.
Leave FENV_EXCEPT as is.
Change the prefix for the rest of the pragmas to FP_, and associate them with math.h.

- Jim Thomas


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20230703/c0397b64/attachment.htm>