struct doesn't handle NaN values?

Grant Edwards grante at visi.com
Thu May 13 21:59:18 EDT 2004


In article <10a88p7deudehca at news.supernews.com>, John Roth wrote:

>>>> Which part of the C library is broken?
>>>
>>> Which C library?
>>
>> That's what I'm askeing?  I was told the C library was broken.
>> I wanted to know what C library.
> 
> The breakage has to do with the character values they use to
> denote infinities and NaN,

Right.  That's got nothing to do with what I'm currently
whining about, which was struct's failure when byte ordering is
specified to convert properly between a native NaN and IEEE 754
NaN (even when native format is IEEE 754) . I'm quite happy
with the way string<->native-float handles NaNs on the host I'm
using.  Not that it wouldn't be nice for it to be consistent
across platforms.

> not (as far as I know) with the detection of them. Whether
> they are "broken" is a matter of interpretation, since the C
> standard didn't specify what the library should expect and
> return when converting from string to float and vice versa.
> What is true is that they aren't consistent.

Though I realize there are consistency issues, they work quite
well enough for my application at the moment. Struct, however,
doesn't.

>> I presumed that struct was doing the conversion itself.  The
>> doc specified IEEE format, it would have to do it's own
>> conversion since it couldn't assume that the host used IEEE
>> format, and as you say, there's no portable library support
>> that can be relied upon.
> 
> I don't think so.

Eh? So you think that struct is using a C library to do the
conversion, or that there is portable C library support for
converting between native FP format and IEEE 754?

> I believe that the reference to IEEE means that it generally
> expects bit compatible IEEE representations.

Hmm, what would be the difference would be between standrd IEEE
representation and a "bit-compatible IEEE representation".

> There may be differences, but I doubt if struct is aware of
> them. As usual, the source would be definitive.
> 
>>> It also contains a reference to a module that handles the
>>> matter.
>>
>> I read it.  It only handles double-precision values, and I'm
>> working with single-precision values.
> 
> I expect it would be easy enough to convert. I just read it,
> and it doesn't look at all complicated.

Probably not.  I've done it before (in C) but having struct
convert the values properly would be right thing to do rather
expect the user to check for certain values that struct doesn't
convert correctly.

-- 
Grant Edwards                   grante             Yow!  My LESLIE GORE record
                                  at               is BROKEN...
                               visi.com            



More information about the Python-list mailing list