Motion P1788/M0051:IntervalLiteralsText: YES
I vote YES on the text of clause 12.11 (Oct 24 version)
I have some minor comments that might be taken into account
in a final editing phase:
In the 3rd paragraph is the sentence:
In this standard, number (and integer) literals are only used
within interval literals.
The next sentence does clarify the above -- but I think it would
be clearer if instead we had:
This standard's specification of number (and integer) literals
applies only within interval literals.
Subclause (b) of 12.11.2 properly matches the 754-2008 mandatory
hex-format exponent field. I had suggested this (late fix), but
forgot the principle of permissive input vs prescriptive output.
I think we are still ok however, because the next paragraph says
that "an implementation may support a more general form", which
would indeed permit (but not require) acceptance of hex-format
input without an exponent part (for example, atof() in libc).
A bit below, default locale, I would prefix "e.g." to "C locale".
Clause 12.11.3 defines "ulp" quite generally, including for hexadecimal
formats -- but then 12.11.4 never exploits this. I'm not suggesting
that we require support for uncertain hexadecimal forms, but we might
point out that such support is conceivable: there could be a "0x"
between the sign and the first digit, and the only question is whether
any exponent would be introduced with a "p" or an "e": I guess "p".
For 12.11.4 (b), singleton format: I would add "where x is given",
to make sure "[]" is not interpreted as "[-inf,+inf]" by expanding
a null string x.
Michel.
---Sent: 2013-10-29 20:41:54 UTC