[Python-Dev] [Python-checkins] r41972 - python/branches/ssize_t/Objects/funcobject.c (original) (raw)

Tim Peters tim.peters at gmail.com
Sun Jan 8 17:42:09 CET 2006

[neal.norwitz]

PyErrFormat(PyExcValueError, - "%s() requires a code object with %d free vars," - " not %d", + "%s() requires a code object with %ld free vars," + " not %ld", PyStringAsString(op->funcname), nclosure, nfree);

[Martin v. Löwis]

I'm not sure whether this is the right fix. This says nclosure and nfree are longs; this is true on most 32-bit systems (where ssizet is int and int and long have the same width), and on some 64-bit systems (where ssizet and long are the same). It does not work for Win64 (where ssizet is larger than long).

Ya, that doesn't work. We'll have similar problems with obmalloc debug output if obmalloc is changed to escape 32-bitness on Win64 -- and anywhere else we need to format one of these things.

I'm tempted to use %zd in these places, but fear that it isn't portable enough (it is part of C99).

MS VC 7.1 doesn't support the z length qualifier, and I expect that kills it right there. So we need a macro, say Py_SIZE_T_WIDTH, in pyport.h:

/* Length qualifier for use in formats when printing size_t or Py_ssize_t values. */ #ifndef Py_SIZE_T_WIDTH

define Py_SIZE_T_WIDTH "z"

#endif

That handles C99-ish platforms by defalt. Other platforms (like Windows) would need to supply their own expansion in their pyconfig.h. Neal's format would become the god-awful but platform-neutral:

      "%s() requires a code object with %" Py_SIZE_T_WIDTH "d free vars,"
      " not %" Py_SIZE_T_WIDTH "d"

I suspect we're going to have other problems when someone gets around to passing a size_t-ish value to PyString_Format() or PyErr_Format(). Maybe we could teach those about the "z" qualifier on all platforms.

More information about the Python-Dev mailing list