[Cfp-interest 3084] Re: text of the strto* and wcstodN functions

Jim Thomas jaswthomas at sbcglobal.net
Sun Apr 7 09:47:43 PDT 2024


[Cfp-interest 3079] says
> On 2024-04-06 15:03:15 -0700, Jim Thomas wrote:
> > The issues below are represented in Issue 19 in C26D.
> > 
> > > On Feb 20, 2024, at 8:22 AM, Vincent Lefevre <vincent at vinc17.net <http://mailman.oakapple.net/mailman/listinfo/cfp-interest>> wrote:
> > > 
> > > On 2024-02-19 09:10:29 -0800, Jim Thomas wrote:
> > >> The Description for the strtodN function says: "If all subject
> > >> sequences of hexadecimal form are correctly rounded, …”. I think in
> > >> context the meaning will be correctly understood as: for these
> > >> inputs the result delivered by the function is correctly rounded.
> > >> The Description of wcstodN has the same wording.
> > > 
> > > Well, this is poor wording. The following is based on N3149.
> > > 
> > > First, there are some issues in other parts of the text, including
> > > for strtod, strtof and strtold:
> > > 
> > > 7.24.1.5p4 says "If the subject sequence has the expected form
> > > for a floating-point number, the sequence of characters starting
> > > with the first digit or the decimal-point character [...]", but
> > > infinities are floating-point numbers.
> > 
> > > So, for instance, this
> > > does not make sense for "INF". I think that it should have said
> > > "finite number" instead of "floating-point number" (note that
> > > it is not a finite floating-point number before conversion, and
> > > due to overflow, it may become infinite).
> > > 
> > > There is the same issue in 7.24.1.6p4 for the strtodN functions.
> > 
> > Infinities are not floating-point numbers. See 5.2.5.3.3 #3 and #8.
> > I think either “floating-point number” or “finite number” would be
> > correct here. The latter seems more direct.
> 
> OK, that's a confusion with IEEE 754, where infinities are
> floating-point numbers. 
Yes, the two standards define the term differently.
> But the use of "floating-point number" is
> incorrect here, because in 5.2.5.3.3, a floating-point number is
> restricted to be written in base b with a precision p (not more).
> For strtodN, this does not make sense.
I think the model can be applied (well enough) to strtodN input, taking b be 10 (for decimal form) or 16 (for hexadecimal form) and the p to be the number of digits in the subject sequence. But I agree “finite number” is a better term here.
> 
> But also, note that the standard sometimes says "finite floating-point
> number".
There are other places where a redundant qualifier is placed on a term — for emphasis, or to help readers who might misinterpret the unqualified term (whether this is really a help is a separate issue), or because text was added at different times (maybe different decades) with different understandings of the meaning of the terms. 
> 
> The term "floating-point number" is also used for ceil and floor
> (James Kuyper had already pointed this issue in comp.std.c in
> August 2021).
This might have been lost. 

CFP should address these cases (“floating-point number” in strtod, strtodN, ceil, floor) and review the use of “floating-point number” in other cases. This could all be done under Issue 19.

- Jim Thomas
> 
> -- 
> Vincent Lefèvre <vincent at vinc17.net <http://mailman.oakapple.net/mailman/listinfo/cfp-interest>> - Web: <https://www.vinc17.net/>
> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20240407/9a2641d0/attachment.htm>


More information about the Cfp-interest mailing list