[Cfp-interest] outstanding issues

[Rajan Bhakta]

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.

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/6aa441b3/attachment-0001.html