You are right. The format should be &#39;l&#39;. I overlooked that. In my case the optional &#39;buf_size&#39; parameter of &#39;decompress&#39; is not used anyhow.<br>Shall I change the patch accordingly?<br><br>It work well for me and I now checked the code of PyArg_ParseTuple (Python/getargs.c) to see what happens. As far as I understand, the given pointer is casted to a pointer to int if the format is &#39;i&#39; (line&nbsp; 630) . On a 64 bit machine this leads to a downcast from a (64 bit) long to a (32 bit) int, which is OK AFAIK, but I could be wrong. 
<br><br>Thanks for pointing that out,<br>Peter<br><div><span class="gmail_quote">2007/11/2, Guido van Rossum &lt;<a href="mailto:report@bugs.python.org">report@bugs.python.org</a>&gt;:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>Guido van Rossum added the comment:<br><br>I trust that there&#39;s a problem, but this can&#39;t be right -- the address<br>of r_strlen is passed to PyArg_ParseTuple corresponding to an &#39;i&#39; format<br>letter.&nbsp;&nbsp;That will never do.
<br><br>----------<br>assignee:&nbsp;&nbsp;-&gt; nnorwitz<br>nosy: +gvanrossum, nnorwitz<br><br>__________________________________<br>Tracker &lt;<a href="mailto:report@bugs.python.org">report@bugs.python.org</a>&gt;<br>&lt;<a href="http://bugs.python.org/issue1372">
http://bugs.python.org/issue1372</a>&gt;<br>__________________________________<br></blockquote></div><br>