[Cfp-interest] outstanding issues

[Jim Thomas]

On Apr 11, 2012, at 10:44 AM, Rajan Bhakta wrote:

> ISSUE 4: Do we need to do add wide character strfrom functions (freestanding implementations are not required to support wide characters)? 
> 
> My opinion is yes as for worldwide adoption, wide characters are common. This does makes it harder to implement which may reduce adoption though. 

Assuming we put the wide character strfrom functions in wchar.h, freestanding implementations wouldn't have to implement them to conform. If an implementation supports wchar.h and the strfrom functions in stdlib.h, then adding the wide character strfrom functions to wchar.h wouldn't be much more work.

-Jim
 
> 
> ISSUE 5: Is it appropriate for this floating-point TS to specify integer strfrom functions? 
> 
> My opinion is no. We should focus on floating point types and not the integer types. Allowing this may impose a burden or otherwise hinder implementers (ex. DSP chips). 
> 
> ISSUE 6: The macro names FP_CEIL, etc. might suggest results will be in floating types. 
> 
> I agree with the proposed change. 
> 
> Rajan 
> 
> 
> From:	Jim Thomas <jaswthomas at sbcglobal.net>
> To:	CFP <cfp-interest at ucbtest.org>
> Date:	04/10/2012 07:37 PM
> Subject:	[Cfp-interest] outstanding issues
> Sent by:	cfp-interest-bounces at oakapple.net
> 
> 
> 
> 
> 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.
> _______________________________________________
> Cfp-interest mailing list
> Cfp-interest at oakapple.net
> http://mailman.oakapple.net/mailman/listinfo/cfp-interest
> 
> 
> 

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