[Python-Dev] PyMarshal_WriteLongToFile: writes 'long' or 32-bitinteger?

Tim Peters tim_one@email.msn.com
Tue, 6 Jun 2000 14:36:26 -0400


[GregS]
> It isn't only bytecodes. As I mentioned before, marshal byte streams are
> specified as portable. Therefore, they are used all the time for passing
> over the network, for persistence mechanisms, etc.
>
> Having a marshal stream that is *not* cross-platform is just plain busted.
>
> So... you can silently truncate to 32-bits or you can raise an exception.

But in either of those cases it's not cross-platform == it's just plain
busted.

> You cannot, however, marshal a 64-bit value when the definition of an
> "marshal integer" is only 32.

The current code is insane.  Long-term the visible distinction between
(Python) ints and longs should vanish.  Short-term the PyInt_Check case of
w_object should see whether the int fits in 4 bytes, and if so write it as a
C long, and if not write the thing as a Python long (that's the only way to
keep the marshal portable!).  Any code keying off the SIZEOF_LONG symbol is
highly suspect, piling another layer of "convenient but wrong" assumptions
on top of the current layer.  Code in marshal should *never* try to exploit
that C longs happen to be bigger than 4 bytes on the current platform.
PyMarshal_WriteLongToFile should be changed to raise an exception if passed
something that doesn't fit in 4 bytes, and should be declared obsolete.  The
Python core should be changed now never to call PyMarshal_WriteLongToFile
(in answer to Trent's original question, the intent of that code can't be
distinguished from what it does, which is to blindly write exactly 4 bytes
no matter what).

Most of this crap is in support of a bad assumption about mtimes, and,
sorry, but it sure looks to me like the .pyc header format is "just plain
busted" too.  Let's bite the bullet and fix the header -- then all the rest
of this will be clearly seen as the broken hackery it really is.