This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: Dodgy functions (finitel, strold)
- From: Doug Henderson <djndnbvg at gmail dot com>
- To: cygwin-apps at cygwin dot com
- Date: Fri, 25 Mar 2016 18:16:13 -0600
- Subject: Re: Dodgy functions (finitel, strold)
- Authentication-results: sourceware.org; auth=none
- References: <announce dot 20160318203409 dot GA11113 at calimero dot vinschen dot de> <56EC6BDA dot 7050505 at cornell dot edu> <20160318214509 dot GD11113 at calimero dot vinschen dot de> <8760whmn3a dot fsf at Rainer dot invalid> <20160320152540 dot GG11113 at calimero dot vinschen dot de> <87wpoxkm28 dot fsf at Rainer dot invalid> <56EF0583 dot 5030302 at cygwin dot com> <87lh58xav0 dot fsf_-_ at Rainer dot invalid> <87h9fvygky dot fsf at Rainer dot invalid> <87r3ezrkz9 dot fsf_-_ at Rainer dot invalid>
On 25 March 2016 at 02:59, Achim Gratz <Stromeko@nexgo.de> wrote:
>
> Achim Gratz writes:
> > Achim Gratz writes:
> >> Long story short, they seem to report a finite value on at least some
> >> NaN constructs and then the %a format for the Perl sprintf outputs those
> >> bits as a hex FP number rather than just printing "NaN". On 64bit the
> >> culprit is actually finitel, of course, since Perl gets compiled with
> >> long doubles.
> >
> > And looking into newlib this seems to be a compile bug, because the
> > function just uses an intrinsic.
>
> But the compiler is innocent, because newlib uses the wrong intrinsic or
> an incomplete implementation. If it must be using that intrinsic for
> compatibility reasons, it would need to implement
>
> <snip>
>
> Regards,
> Achim.
>
I modified your program to display the actual hex value of the a, b,
and c variables. The b and c variables have different bit patterns. It
appears that the %a format conversion is (correctly) detecting Âinf
and NaN according to IEEE 754, and ignoring the value of all other
bits in the variables.
It appears that strtold and the implicit conversion from double to
long double are setting some of the bits which are not used to
represent NaN or ÂInf to different values.
It appears that some of the different functions that get used to
detect finiteness and validity are sensitive to the setting of other
bits in the values, or are expecting particular values for these bits.
The standard supports two representations of NaN: a signalling NaN and
a non-signalling NaN. From what I could see, the C language does not
distinguish between the two NaN representations, but I did not look at
the standards docs.
HTH,
Doug
--
Doug Henderson, Calgary, Alberta, Canada