[PATCH stable v2] parsers: use 'k' format for Py_BuildValue instead of 'n' because Python 2.4
pierre-yves.david at ens-lyon.org
Wed Oct 22 20:29:17 CDT 2014
On 10/22/2014 05:43 PM, Mads Kiilerich wrote:
> # HG changeset patch
> # User Mads Kiilerich <madski at unity3d.com>
> # Date 1414024977 -7200
> # Thu Oct 23 02:42:57 2014 +0200
> # Branch stable
> # Node ID 5715c93cb8540dc7b6d4dc2d0fde07dfd0ba9033
> # Parent d583f1cfca9670946d7e315df4d0a0efccb7a612
> parsers: use 'k' format for Py_BuildValue instead of 'n' because Python 2.4
> 'n' was introduced in Mercurial in 2b5940f64750 and broke Python 2.4 support in
> mysterious ways that only showed failure in test-glog.t. Py_BuildValue failed
> because of the unknown format and a TypeError was thrown ... but it never
> showed up on the Python side and it happily continued processing with wrong
> Quoting https://docs.python.org/2/c-api/arg.html :
> n (integer) [Py_ssize_t]
> Convert a Python integer or long integer to a C Py_ssize_t.
> New in version 2.5.
> k (integer) [unsigned long]
> Convert a Python integer or long integer to a C unsigned long without
> overflow checking.
> This will use unsigned long instead of Py_ssize_t. That is not a good solution,
> but good is not an option when we have to support Python 2.4.
This seems reasonable (lgtm) I would prefer patch1 to be sorted out
before pushing this.
More information about the Mercurial-devel