On Sunday, September 9, 2012 6:17:49 PM UTC+4, Bram Moolenaar wrote: > Maxim Philippov wrote: > > > > [...] > > > > > > If i'm correct then instead of Py_ssize_t len = 0, you should > > > > replace that line with PyInt len; > > > > > > > > This will be defined correctly near the top of if_python.c and work > > > > in both cases. In any case, my original patch should have been done > > > > that way. Ugh. > > > > [...] > > > > > Hi Sean. > > > > > > Finally I get it =) Since vim may load libpython dynamically, > > > PY_SSIZE_T_CLEAN doesn't do its macro magic, namely it doesn't change > > > PyArg_ParseTuple symbol name to _PyArg_ParseTuple_SizeT (as You can > > > see in /usr/include/python*/modsupport.h). > > > > > > Now patch is a bit more complicated, please look attached > > > py_sizet_syms.patch > > > > Do I understand it correctly that this goes on top of the patch that > > changes the type of "len"? > > > > How do I describe the problem this fixes in one or two sentences? >
Hi Bram, Yes, this caused by patch that changes the type of "len". On x86_64 Linux "len"'s size is 8 bytes (Py_ssize_t), but function PyArg_ParseTuple expects "len" to be 4 bytes (int). So "len" is half-set after call, we need to load and use _PyArg_ParseTuple_SizeT instead. Maxim -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
