[neal.norwitz]
>> PyErr_Format(PyExc_ValueError,
>> - "%s() requires a code object with %d free vars,"
>> - " not %d",
>> + "%s() requires a code object with %ld free vars,"
>> + " not %ld",
>> PyString_AsString(op->func_name),
>> 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 ssize_t is int
> and int and long have the same width), and on some 64-bit systems (where
> ssize_t and long are the same). It does not work for Win64 (where
> ssize_t 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.
_______________________________________________
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
