[Python-Dev] Re: marshal / unmarshal
tim.peters at gmail.com
Tue Apr 12 17:16:22 CEST 2005
>>> I recall stories of machines that stored the bytes of long in some
>>> crazy order like that. I think Python would already be broken on such
>>> a system, but, also, don't care.
>> Python does very little that depends on internal native byte order,
>> and C hides it in the absence of casting abuse.
> This surely does:
> PyObject *
> PyLong_FromLongLong(PY_LONG_LONG ival)
> PY_LONG_LONG bytes = ival;
> int one = 1;
> return _PyLong_FromByteArray(
> (unsigned char *)&bytes,
> SIZEOF_LONG_LONG, IS_LITTLE_ENDIAN, 1);
Yes, that's "casting abuse'. Python does very little of that. If it
becomes necessary, it's straightforward but long-winded to rewrite the
above in wholly portable C (peel the bytes out of ival,
least-signficant first, via shifting and masking 8 times; "ival &
0xff" is the least-significant byte regardless of memory storage
order; etc). BTW, the IS_LITTLE_ENDIAN macro also relies on casting
abuse, and more deeply than does the visible cast there.
> It occurs that in the IEEE case, special values can be detected with
> reliablity -- by picking the exponent field out by force
Right, that works for NaNs and infinities; signed zeroes are a bit
trickier to detect.
> -- and a warning emitted or exception raised. Good idea? Hard to say, to me.
It's not possible to _create_ a NaN or infinity from finite operands
in 754 without signaling some exceptional condition. Once you have
one, though, there's generally nothing exceptional about _using_ it.
Sometimes there is, like +Inf - +Inf or Inf / Inf, but not generally.
Using a quiet NaN never signals; using a signaling NaN almost always
So packing a nan or inf shouldn't complain. On a 754 box, unpacking
one shouldn't complain either. Unpacking a nan or inf on a non-754
box probably should complain, since there's in general nothing it can
be unpacked _to_ that makes any sense ("errors should never pass
More information about the Python-Dev