[Cfp-interest] outstanding issues

[Jim Thomas]

Greetngs all,

Below is a list of outstanding issues for the CFP draft TS Part 1. Email discussion in advance of our teleconference next week (4/19) would improve the chances of resolving the issues during the meeting.

-Jim


ISSUE 1: Is requiring freestanding support for part of a header ok?

The partial header approach was proposed by a member of WG14 (the C committee) and we've had no response from others on WG14 about it. Unless CFP has an issue with it, I suggest we leave it to WG14 to object if they wish.


ISSUE 2: Make F.1 more readable.

Here's F.1 broken into three paragraphs, which I think helps some:

This annex specifies C language support for the IEC 60559 floating-point standard. The IEC 60559 floating-point standard is specifically Floating-point arithmetic (ISO/IEC/IEEE 60559:2011), also designated as IEEE Standard for Floating-Point Arithmetic (IEEE 754−2008). The IEC 60559 floating-point standard supersedes the IEC 60559:1989 binary arithmetic standard, also designated as IEEE Standard for Binary Floating-Point Arithmetic (IEEE 754−1985). IEC 60559 generally refers to the floating-point standard, as in IEC 60559 operation, IEC 60559 format, etc.

The IEC 60559 floating-point standard specifies decimal, as well as binary, floating-point arithmetic. It supersedes IEEE Standard for Radix-Independent Floating-Point Arithmetic (ANSI/IEEE 854−1987), which generalized the binary arithmetic standard (IEEE 754-1985) to remove dependencies on radix and word length.

An implementation that defines __STDC_IEC_60559_BFP__ to 201ymmL shall conform to the specifications in this annex.356) Where a binding between the C language and IEC 60559 is indicated, the IEC 60559-specified behavior is adopted by reference, unless stated otherwise.


ISSUE 3: Would it be better to restrict the format specifiers that the strfrom functions have to support?

From Rajan:

Replace

NOTE    If the conversion specifier (in the string pointed to by format) for x is not applicable to type double or long double, the behavior of strfromd or strfromld, respectively, is undefined.

with

NOTE  The format string must support specifying the precision, the floating point conversion specifiers (a, A, e, E, f, F, g, G), and the length modifier (L). An implementation may add any other format string support. If any other format string not explicitly supported by the implementation is present, the behaviour is undefined.

Recommended practice: The equivalent of hosted support for conversion specifiers for snprintf should be allowed.

I think the question here is whether the simplicity achieved is worth the formatting functionality lost? Think of adapting Tydeman suite for freestanding.


ISSUE 4: Do we need to do add wide character strfrom functions (freestanding implementations are not required to support wide characters)?

If CFP doesn't have a strong opinion, we might leave this as an issue for WG14.


ISSUE 5: Is it appropriate for this floating-point TS to specify integer strfrom functions?

Do freestanding implementations already have functions that convert integers to character sequences? atoi? 


ISSUE 6: The macro names FP_CEIL, etc. might suggest results will be in floating types.

How about FP_INT_UPWARD, etc.? These: indicate that integers are involved and don’t refer to ceil so don't suggest conversion to floating type; are different enough from FE_UPWARD, etc. to avoid mixing them up; start with FP like most other macros in math.h; and aren't too terribly long.


ISSUE 7: Should the 7.12 specification of llogb require a domain error for finite out-of-range cases? Waiting for C committee resolution of a DR about the same issue for ilogb.

This is resolved, for now.


ISSUE 8: Forward references need to be added throughout.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20120410/34535a4e/attachment.html