changeset 23073:5715c93cb854 stable

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 data. 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.
author Mads Kiilerich <madski@unity3d.com>
date Thu, 23 Oct 2014 02:42:57 +0200
parents d583f1cfca96
children 21a55dbc3940
files mercurial/parsers.c
diffstat 1 files changed, 3 insertions(+), 2 deletions(-) [+]
line wrap: on
line diff
--- a/mercurial/parsers.c	Mon Oct 20 18:50:09 2014 -0700
+++ b/mercurial/parsers.c	Thu Oct 23 02:42:57 2014 +0200
@@ -873,12 +873,13 @@
 	return newlist;
 }
 
-static int check_filter(PyObject *filter, Py_ssize_t arg) {
+/* arg should be Py_ssize_t but Python 2.4 do not support the n format */
+static int check_filter(PyObject *filter, unsigned long arg) {
 	if (filter) {
 		PyObject *arglist, *result;
 		int isfiltered;
 
-		arglist = Py_BuildValue("(n)", arg);
+		arglist = Py_BuildValue("(k)", arg);
 		if (!arglist) {
 			return -1;
 		}