Re: Dodgy functions (finitel, strold)

[Doug Henderson <djndnbvg@gmail.com>]

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