Re: [PATCH v5] stdlib/strfrom: Add copysign to fix NAN issue on riscv (BZ #29501)

[Letu Ren <fantasquex@gmail.com>]

> According to the specification of ISO/IEC TS 18661-1:2014,
>
> The strfromd, strfromf, and strfroml functions are equivalent to
> snprintf(s, n, format, fp) (7.21.6.5), except the format string contains only
> the character %, an optional precision that does not contain an asterisk *, and
> one of the conversion specifiers a, A, e, E, f, F, g, or G, which applies to
> the type (double, float, or long double) indicated by the function suffix
> (rather than  by a length modifier). Use of these functions with any other 20
> format string results in undefined behavior.
>
> strfromf will convert the arguement with type float to double first.
>
> According to the latest version of IEEE754 which is published in 2019,
>
> Conversion of a quiet NaN from a narrower format to a wider format in the same
> radix, and then back to the same narrower format, should not change the quiet
> NaN payload in any way except to make it canonical.
>
> When either an input or result is a NaN, this standard does not interpret the
> sign of a NaN. However, operations on bit strings—copy, negate, abs,
> copySign—specify the sign bit of a NaN result, sometimes based upon the sign
> bit of a NaN operand. The logical predicates totalOrder and isSignMinus are
> also affected by the sign bit of a NaN operand. For all other operations, this
> standard does not specify the sign bit of a NaN result, even when there is only
> one input NaN, or when the NaN is produced from an invalid operation.
>
> converting NAN or -NAN with type float to double doesn't need to keep
> the signbit. As a result, this test case isn't mandatory.
>
> The problem is that according to RISC-V ISA manual in chapter 11.3 of
> riscv-isa-20191213,
>
> Except when otherwise stated, if the result of a floating-point operation is
> NaN, it is the canonical NaN. The canonical NaN has a positive sign and all
> significand bits clear except the MSB, a.k.a. the quiet bit. For
> single-precision floating-point, this corresponds to the pattern 0x7fc00000.
>
> which means that conversion -NAN from float to double won't keep the signbit.
>
> Since glibc ought to be consistent here between types and architectures, this
> patch adds copysign to fix this problem if the string is NAN. This patch
> adds two different functions under sysdeps directory to work around the
> issue.
>
> This patch has been tested on x86_64 and riscv64.
>
> Resolves: BZ #29501
>
> v2: Change from macros to different inline functions.
> v3: Add unlikely check to isnan.
> v4: Fix wrong commit message header.
> v5: Fix style: add space before parentheses.
> Signed-off-by: Letu Ren <fantasquex@gmail.com>
> ---
> I'm not sure about copyright of the new file I created and the name of
> the new function. Please give me some advice. Thanks.

Hi, it has been almost a week since this patch was sent. I'm looking
forward to any response.

Thanks.
Letu Ren