[PATCH STABLE] parsers: fix width of datalen variable in fm1readmarkers

[Yuya Nishihara]

On Sat, 07 Nov 2015 16:27:43 -0500, Pierre-Yves David wrote:
> On 11/07/2015 05:59 AM, Yuya Nishihara wrote:
> > # HG changeset patch
> > # User Yuya Nishihara <yuya at tcha.org>
> > # Date 1446885800 -32400
> > #      Sat Nov 07 17:43:20 2015 +0900
> > # Branch stable
> > # Node ID 70776f5ecbcd42f94cbe2d3c81f858b5bff8e466
> > # Parent  10a1a4b3e775d6024a82937df6bcc4188a315124
> > parsers: fix width of datalen variable in fm1readmarkers
> 
> 
> >
> > Because parsers.c does not define PY_SSIZE_T_CLEAN, "s#" format requires
> > (const char*, int), not (const char*, Py_ssize_t).
> 
> very nice catch
> 
> My only fear here is that "int" is not actually defined as 32bits in the 
> standard. Did the C compiler world came to its senses about that or do 
> we have to go for some stdint stuff?
> 
> Given that mercurial/util.h is using uint32_t, I assume we should 
> probably use it here too.

No, "int" is correct here because that is the requirement of PyArg_ParseTuple().
If PY_SSIZE_T_CLEAN is not defined, the argument is processed as an int.
Therefore, upper bits of "Py_ssize_t datalen" was uninitialized on little-endian
machine.

https://hg.python.org/cpython/file/v2.7.10/Python/getargs.c#l585

Perhaps we should use PY_SSIZE_T_CLEAN consistently to avoid this kind of bugs.