public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug math/28322] New: Specify parsing of nan?
@ 2021-09-09 12:21 arthur200126 at gmail dot com
2021-09-09 13:55 ` [Bug math/28322] " arthur200126 at gmail dot com
` (4 more replies)
0 siblings, 5 replies; 6+ messages in thread
From: arthur200126 at gmail dot com @ 2021-09-09 12:21 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug math/28322] Specify parsing of nan?
2021-09-09 12:21 [Bug math/28322] New: Specify parsing of nan? arthur200126 at gmail dot com
@ 2021-09-09 13:55 ` arthur200126 at gmail dot com
2021-09-09 14:02 ` arthur200126 at gmail dot com
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: arthur200126 at gmail dot com @ 2021-09-09 13:55 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug math/28322] Specify parsing of nan?
2021-09-09 12:21 [Bug math/28322] New: Specify parsing of nan? arthur200126 at gmail dot com
2021-09-09 13:55 ` [Bug math/28322] " arthur200126 at gmail dot com
@ 2021-09-09 14:02 ` arthur200126 at gmail dot com
2021-09-09 17:09 ` joseph at codesourcery dot com
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: arthur200126 at gmail dot com @ 2021-09-09 14:02 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug math/28322] Specify parsing of nan?
2021-09-09 12:21 [Bug math/28322] New: Specify parsing of nan? arthur200126 at gmail dot com
2021-09-09 13:55 ` [Bug math/28322] " arthur200126 at gmail dot com
2021-09-09 14:02 ` arthur200126 at gmail dot com
@ 2021-09-09 17:09 ` joseph at codesourcery dot com
2021-09-11 11:41 ` arthur200126 at gmail dot com
2021-09-11 11:57 ` arthur200126 at gmail dot com
4 siblings, 0 replies; 6+ messages in thread
From: joseph at codesourcery dot com @ 2021-09-09 17:09 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug math/28322] Specify parsing of nan?
2021-09-09 12:21 [Bug math/28322] New: Specify parsing of nan? arthur200126 at gmail dot com
` (2 preceding siblings ...)
2021-09-09 17:09 ` joseph at codesourcery dot com
@ 2021-09-11 11:41 ` arthur200126 at gmail dot com
2021-09-11 11:57 ` arthur200126 at gmail dot com
4 siblings, 0 replies; 6+ messages in thread
From: arthur200126 at gmail dot com @ 2021-09-11 11:41 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug math/28322] Specify parsing of nan?
2021-09-09 12:21 [Bug math/28322] New: Specify parsing of nan? arthur200126 at gmail dot com
` (3 preceding siblings ...)
2021-09-11 11:41 ` arthur200126 at gmail dot com
@ 2021-09-11 11:57 ` arthur200126 at gmail dot com
4 siblings, 0 replies; 6+ messages in thread
From: arthur200126 at gmail dot com @ 2021-09-11 11:57 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-09-11 11:57 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-09-09 12:21 [Bug math/28322] New: Specify parsing of nan? arthur200126 at gmail dot com
2021-09-09 13:55 ` [Bug math/28322] " arthur200126 at gmail dot com
2021-09-09 14:02 ` arthur200126 at gmail dot com
2021-09-09 17:09 ` joseph at codesourcery dot com
2021-09-11 11:41 ` arthur200126 at gmail dot com
2021-09-11 11:57 ` arthur200126 at gmail dot com
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).