[Python-Dev] ssize_t branch merged

[Thomas Wouters]

On Fri, Feb 17, 2006 at 04:40:08PM -0700, Travis Oliphant wrote:

> What is PY_SSIZE_T_MAX supposed to be?  The definition in pyport.h 
> doesn't compile.

Why not? Does it give an error for your particular platform? What platform
is that? What are HAVE_SSIZE_T, SIZEOF_VOID_P and SIZEOF_SIZE_T defined to
be?

While looking at the piece of code in Include/pyport.h I do notice that the
fallback (when ssize_t is not available) is to Py_uintptr_t... Which is an
unsigned type, while ssize_t is supposed to be signed. Martin, is that on
purpose? I don't have any systems that lack ssize_t. ;P

That should prevent the PY_SSIZE_T_MAX definition from compiling though.

> Shouldn't a lot of checks for INT_MAX be replaced with PY_SSIZE_T_MAX? 
> Like in the slice indexing code?

Yes, ideally. (Actually, I think slice indexing was changed earlier today.)
But while changing it would have little to no effect on 32-bit machines,
doing it the wrong way may break the code on 64-bit machines in subtle ways,
so it's not all done blindly, or in one big shot. Also, because some output
parameters to PyArg_ParsE* change size (s#/t#), code will have to be
reviewed to make use of the full address range anyway. (There's some
preprocessor hackery that checks for PY_SIZE_T_CLEAN to see if it's safe to
use the large output versions.)

Adapting all code in the right way isn't finished yet (not in the last place
because some of the code is... how shall I put it... 'creative'.)

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!