# HG changeset patch
# User Siddharth Agarwal <sid0@fb.com>
# Date 2015-04-06 17:46:44
# Node ID 6f0e6fa9fdd700807fe252a4caa9191b05e5fe0f
# Parent  2262d7bc469edf95a6c58c4833e8474a20a95281

dirs._addpath: don't mutate Python strings after exposing them (issue4589)

One of the rules of Python strings is that they're immutable. dirs._addpath
breaks this assumption for performance, which is fine as long as it is done
safely -- once a string is no longer internal-only it shouldn't be mutated.
Unfortunately, we weren't being safe here -- we were mutating 'key' even after
adding it to a dictionary.

This only really affects other C code that reads strings, so it's somewhat hard
to write a test for this without poking into the internal representation of the
string via ctypes or similar. There is currently no C code that reads the
output of the string, but there will likely be some soon as the bug indicates.

There's no significant difference in performance.

diff --git a/mercurial/dirs.c b/mercurial/dirs.c
--- a/mercurial/dirs.c
+++ b/mercurial/dirs.c
@@ -93,11 +93,11 @@ static int _addpath(PyObject *dirs, PyOb
 		if (ret == -1)
 			goto bail;
 
-		if (pos != 0)
-			PyString_AS_STRING(key)[pos] = '/';
-		else
-			key = NULL;
-		Py_CLEAR(key);
+		/* Clear the key out since we've already exposed it to Python
+		   and can't mutate it further. key's refcount is currently 2 so
+		   we can't just use Py_CLEAR. */
+		Py_DECREF(key);
+		key = NULL;
 	}
 	ret = 0;