[Bug math/28322] New: Specify parsing of nan?

[Bug math/28322] New: Specify parsing of nan?

[arthur200126 at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=28322

            Bug ID: 28322
           Summary: Specify parsing of nan?
           Product: glibc
           Version: 2.35
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P2
         Component: math
          Assignee: unassigned at sourceware dot org
          Reporter: arthur200126 at gmail dot com
  Target Milestone: ---

The current glibc documentation at [1] states:
  [1]:
https://www.gnu.org/software/libc/manual/html_node/Parsing-of-Floats.html

> The strings "nan" and "nan(chars…)" are converted to NaN. Again, case is
> ignored. If chars… are provided, they are used in some unspecified fashion to
> select a particular representation of NaN (there can be several).

I find this documentation odd as glibc itself appears to have one single method
for parsing the "chars..." part in nan, defined in the source files
strtod_nan_*.c. Moreover, since commit
e02cabecf0d025ec4f4ddee290bdf7aadb873bb3,[2] the format is locale-independent,
making it more conducive to documentation. 

  [2]:
https://sourceware.org/git/?p=glibc.git;a=commit;h=e02cabecf0d025ec4f4ddee290bdf7aadb873bb3

A proposed wording for the current behavior would be:

> If chars... are provided, they are parsed into a NaN payload as if the
> sequence is given to strtoull() with a base argument of 0. (Something about
> discarding stray characters here.)

I should note that there is still ambiguity in "parsed into a payload" with
regard to how. Apparently glibc has a setpayload(), but the SET_NAN_PAYLOAD
macro does not use it.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug math/28322] Specify parsing of nan?

[arthur200126 at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=28322

--- Comment #1 from Mingye Wang <arthur200126 at gmail dot com> ---
Well uh... after a cursory look at the macro and the setpayload() function,
they appears to do the same thing. So the part can just say something like
"parsed into a quiet NaN payload", optionally with "which is defined as an
integer value per IEEE" (see [1]).

  [1]: https://www.gnu.org/software/libc/manual/html_node/FP-Bit-Twiddling.html

The datatypes involved in get/setpayload stuff confused me a bit.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug math/28322] Specify parsing of nan?

[arthur200126 at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=28322

--- Comment #2 from Mingye Wang <arthur200126 at gmail dot com> ---
I think the documentation should also mention that the behavior is identical to
that of nan{,f,l} functions, but they do not appear in the Texinfo
documentation at all.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug math/28322] Specify parsing of nan?

[joseph at codesourcery dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=28322

--- Comment #3 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
Note the oddity that the parsing of NaN payloads from strings can't handle 
integers larger than 64 bits (given the use of strtoull), when _Float128 
(long double on some architectures) has 111 payload bits and arguably 
strings corresponding to all possible 111-bit payloads should be parsed 
(so requiring adding code to glibc to handle parsing strings to 128-bit 
integers for this purpose - including on some architectures that don't 
have __int128 support).  That leads to the question of whether that oddity 
should be documented, or considered as a bug (or both).

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug math/28322] Specify parsing of nan?

[arthur200126 at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=28322

--- Comment #4 from Mingye Wang <arthur200126 at gmail dot com> ---
Hmm... for my "little documentation bug" I am inclined to keep the code as-is.
I guess some documentation would do -- probably just a parenthetical after
strtoull() saying "for a maximum width of 64-bit" or whatever.

The strtou128() or whatever would be nice for systems with __int128 support,
but feels both pointless and harder to fit into the current myriad of
macro-generic code for systems without. Tying them onto the float thing seems
to require a lot of explaining about when 128-bit is involved. (But on the
other hand... _Float128 without int128 is unlikely, rrright?)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug math/28322] Specify parsing of nan?

[arthur200126 at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=28322

--- Comment #5 from Mingye Wang <arthur200126 at gmail dot com> ---
An argument for expanding it to larger integers would be for GCC builtin
compatibility. GCC's __builtin_nan() currently acts the same as glibc's
strtod() and nan(), but for __builtin_nanf128() they do extend out to cover all
bits of payload.

https://gcc.godbolt.org/z/E6Kdcb64a

-- 
You are receiving this mail because:
You are on the CC list for the bug.