struct doesn't handle NaN values?

[Tim Peters]

[Grant Edwards]
> There's a table that clearly defines when it [struct] uses "native" vs.
> "standard" byte-order and size-and-alignment.
>
> One assumes that the floating point _representation_ could
> likewise be native or standard (IEEE),

Yes, this is the case.

> but it never specifies which FP representation is used when.

The same as everything else:  in native mode, whatever float and double
representation the platform uses is what struct uses, just as in native mode
struct uses whatever the platform uses for chars, shorts, ints and longs.
In standard mode, the representation is forced to IEEE 754 float or double
format.  But it's still the case that all behavior wrt NaNs, Infs, and
signed zeroes is an accident in standard mode.  Indeed, it's precisely
*because* standard mode tries to force the representation to a known format
(and Python has no idea whether the platform it's running on uses 754 format
natively or not) that these accidents occur.  C89 predates 754 adoption, and
so offers no portable facilities even for recognizing whether a thing is a
NaN, Inf, or signed 0.  "Standard" C tricks like

    if (x != x) { /* then x is a NaN */ }

don't actually work across platforms (although many with limited x-platform
experience believe they do).

> Since "IEEE" is mentioned in the discussion of "standard size and
> alignment",

And only there.

> I would guess that FP native vs. standard representation
> matches the native vs. standard state of "size and alignment".

I'm not sure what that sentence said, but bet it's right <wink>.