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. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds