Python on Itanium Windows 64: available or planned?

Martin v. Löwis martin at
Mon Nov 3 23:28:15 CET 2003

"Mike Rovner" <mike at> writes:

> > That may even be a source of bugs. I'm in the process of putting
> > size_t in every place Python currently uses "int" or "long" to store a
> > number of bytes. In some cases, exceeding 4GB (sometimes 2GB) will
> > cause crashes in Python 2.3 (in other cases, this is somewhat overkill
> > - eg. when the compiler complains that strlen(some_file_name) may not
> > fit into 4 bytes).
> Does that mean forthcoming API interface change?

Yes. I haven't changed any structure (yet), but, after approval on
python-dev, this is likely to happen as well.

> There are mostly ints for sizes (ex. PyString_AsStringAndSize
> (PyObject *obj, char **buffer, int *length)).

Indeed. I don't think it matters, though: processors typically return
results in registers. On a 64-bit processor, a single register will
take the result, and most likely, a 32-bit return value will be
widened appropriately. So you might actually get away with not
recompiling the extensions in 2.4 (atleast until ob_size changes,
which does cause incompatibilities on big-endian machines).


More information about the Python-list mailing list