[Python-Dev] ssize_t branch merged (original) (raw)

Thomas Wouters thomas at xs4all.net
Sat Feb 18 01:51:49 CET 2006

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

What is PYSSIZETMAX 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 INTMAX be replaced with PYSSIZETMAX? 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!

More information about the Python-Dev mailing list