Investigate Py_ssize_t behavior in wrappers for CPython < 2.5

[nejucomo]

Py_ssize_t was introduced in CPython 2.5 in Pep 353 [1]. Older Python wrappers treated sizes inconsistently.

This ticket is closed when:

1. An explanation is given of how wrapper code that relies on Py_ssize_t compiles in pre 2.5 environments (start with [2]).

2. A unit test is written which determines if code relying on Py_ssize_t behaves correctly on < 2.5 and >= 2.5 platforms.

3. If the unit test shows no distinction between the two version cases, an explanation of why there's no failure in all cases. Otherwise, jump to step b and devise a new unit test.

4. A ticket is opened for each created failing unit test.

[1] ​http://www.python.org/dev/peps/pep-0353/ [2] ​http://www.google.com/search?q=Py_ssize_t

[zooko]

1. Python 2.4 just uses int as the type of values which hold the sizes of arrays. We have the following stanza at the top of each .cpp file:

#if (PY_VERSION_HEX < 0x02050000)
typedef int Py_ssize_t;
#endif

This creates a Py_ssize_t type, which is actually int, if the Python version is < 2.5.0. The only thing to be safe is to pass objects of type Py_ssize_t (instead of int or size_t as I apparently did) to PyArg_ParseTupleAndKeywords() as a "#" argument. Your patch does that.

2. We already have tests of (most of?) the CPython wrapper code, and we already have a Python 2.4 buildbot: ​http://allmydata.org/buildbot-pycryptopp/builders/solaris-amd64-nexenta-nooxie . Is there any more specific way that you can think of to test that the wrapper code is passing an object of the right size as the "#" argument?

3. Explanation is that typedef.

Good? :-)

[zooko]

P.S. Step (e), release a new version of pycryptopp as soon as you've signed off on this ticket...

[zooko]

Everyone please see ​http://allmydata.org/trac/pycryptopp/ticket/19#comment:8 and post your results.

[zooko]

Nej: good enough? Then please close this ticket.

[zooko]

nejucomo closed the sister ticket ​http://allmydata.org/trac/pycryptopp/ticket/19 so I'm closing this one.