This is the mail archive of the
mailing list for the Cygwin project.
Re: Dodgy functions (finitel, strold)
- From: Achim Gratz <Stromeko at nexgo dot de>
- To: cygwin-apps at cygwin dot com
- Date: Fri, 01 Apr 2016 21:04:42 +0200
- 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> <CAJ1FpuO8p2NNERWzXWuahiz91_27_TA3RUP=xJ=UzZZVY1YZVw at mail dot gmail dot com>
Doug Henderson writes:
> 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.
I wasn't concerned about the bit patterns, but the fact that +-Inf was
recognized as valid input, but then converted to NaN.
> 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.
That would be a bug. The standard defines all the valid bit patterns
for each case, so if in doubt you could exhaustively test them.
> 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.
You can mostly ignore that distinction unless the runtime exposes it to
you. In a nutshell, the difference is between silently producing and
then using the NaN in further computation or raising an exception. In
the latter case, the runtime would need to give you a way to catch and
handle the exception.
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Factory and User Sound Singles for Waldorf Blofeld: