_sre.c:match_start currently uses Py_BuildValue("i") to return the start index, which itself is of type Py_ssize_t. This will get truncated on x64 Windows if the start is > 2**31. PyInt_FromSsize_t should be used instead. Other usages of Py_BuildValue should be reviewed as well.

I analyzed all 1-valued usages of Py_BuildValue and found similar bags only in Modules/_sre.h. Here is a patch.

Bugs should be evident on big-endian platform with sizeof(int) < sizeof(size_t) or sizeof(long) < sizeof(size_t). Standard tests should fail on such platforms.

Please review.

Patch looks good to me. Do you think it's possible to add some bigmem tests for this?

I can't write a test, because I have no such big memory.

Actually, standard tests should be enough on a big-endian platform with sizeof(int) < sizeof(size_t) or sizeof(long) < sizeof(size_t).  No additional tests needed.

> Actually, standard tests should be enough on a big-endian platform with 
> sizeof(int) < sizeof(size_t) or sizeof(long) < sizeof(size_t).  No
> additional tests needed.

Ok, thanks. Unfortunately, all our 64-bit big endian buildbots are configured to produce 32-bit Pythons...

Actually, we now have a 64-bit big endian buildbot and it does not show any test failure:
http://buildbot.python.org/all/builders/SPARC%20Solaris%2010%20%28cc%2C%2064b%29%20%5BSB%5D%203.x

[...]
checking size of int... 4
checking size of long... 8
checking size of void *... 8
checking size of short... 2
checking size of float... 4
checking size of double... 8
checking size of fpos_t... 8
checking size of size_t... 8
[...]
checking whether byte ordering is bigendian... yes

Here is a test.

Thanks for the patch. For the record, the test passes successfully but it needs 40 GB, not 4 GB:
http://buildbot.python.org/all/builders/AMD64%20Ubuntu%20LTS%20bigmem%20custom/builds/3

New changeset 0edc92d78192 by Antoine Pitrou in branch '3.2':
Issue #10182: The re module doesn't truncate indices to 32 bits anymore.
http://hg.python.org/cpython/rev/0edc92d78192

New changeset 21ceee08a375 by Antoine Pitrou in branch '3.3':
Issue #10182: The re module doesn't truncate indices to 32 bits anymore.
http://hg.python.org/cpython/rev/21ceee08a375

New changeset e7104cc09d02 by Antoine Pitrou in branch 'default':
Issue #10182: The re module doesn't truncate indices to 32 bits anymore.
http://hg.python.org/cpython/rev/e7104cc09d02

New changeset de0f38f9280e by Antoine Pitrou in branch '2.7':
Issue #10182: The re module doesn't truncate indices to 32 bits anymore.
http://hg.python.org/cpython/rev/de0f38f9280e

Note that this change is causing problems with genshi due to API backward incompatibility.  This is reported here:

https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/1097783

The reason the user found it in Ubuntu first is that we track hg tip, but I've reproduced it in my own hg tip, and the diff of r80680 makes it pretty obvious.

I'm not saying the change should necessarily be reverted, but it *is* a backward incompatibility, and at a minimum the NEWS file (and release notes for 2.7.4) should make it clear that the return types have changed.  As we're seeing, it breaks at least one existing package.

Nosied Benjamin since this is a release issue.  Re-opened, assigned to him, and release blocked for 2.7.4.

Actually, 2.7 should just use PyInt_FromSsize_t, which only promotes when needed.

New changeset 0f5067d9e1d8 by Benjamin Peterson in branch '2.7':
use PyInt_FromSsize_t instead of PyLong_FromSsize_t (#10182)
http://hg.python.org/cpython/rev/0f5067d9e1d8

It's good you were able to report this before we released anything.