On Aug 14 21:17, Masamichi Hosoda wrote:
On Aug 14 11:56, Corinna Vinschen wrote:
On Aug 14 13:45, Masamichi Hosoda wrote:
>From a50ee5a4747a99c70469a53fe959f3dc22d3b79a Mon Sep 17 00:00:00 2001
From: Masamichi Hosoda <trueroad@trueroad.jp>
Date: Tue, 14 Aug 2018 12:50:32 +0900
Subject: [PATCH] Fix strtod ("nan") returns qNaN
The definition of qNaN for x86_64 and x86 was wrong.
So strtod ("nan") returned sNaN instead of qNaN.
Furthermore, it was inverted the sign bit with the presence of `-` character.
So strtod ("-nan") returned qNaN.
This commit fixes definition of qNaN
and removes the sign bit inversion when evaluating "nan".
---
newlib/libc/stdlib/gd_qnan.h | 8 ++++----
newlib/libc/stdlib/strtod.c | 1 +
2 files changed, 5 insertions(+), 4 deletions(-)
[...]
With your patch, strtold looks more correct, but it still prints the
sign of NaN:
strtod ("nan", NULL) = nan
strtod ("-nan", NULL) = nan
strtold ("nan", NULL) = nan
strtold ("-nan", NULL) = -nan
nan ("") = nan
Question: What's wrong with that? Wouldn't it be more correct if
strtod returns -NaN for "-nan" as well?
In my investigate,
strtold sets sign bit when parameter has '-' character.
The wrong long double NaN definition is negative NaN that is set sign bit.
So without my patch, both strtold ("nan") and
strtold ("-nan") return negative NaN.
On the other hand, strtod inverts the sign when parameter has '-' character.
The wrong double NaN definition is negative NaN.
So without my patch, strtod ("nan") returns negative NaN
and strtod ("-nan") returns positive NaN.
Your patch improves the situation, that's a sure thing and I did not
question that.
I just wonder why returning -NaN when the input is "-nan" isn't the
better approach. After all:
printf ("nan (\"\") = %f\n", nan (""));
printf ("-nan (\"\") = %f\n", -nan (""));
==>
nan ("") = nan
-nan ("") = -nan
So, shouldn't the ideal outcome be this:
strtod ("nan", NULL) = nan
strtod ("-nan", NULL) = -nan
strtold ("nan", NULL) = nan
strtold ("-nan", NULL) = -nan
?
Corinna