Issue #3280: like chr() already does, the "%c" format now accepts the full unicode range

even on "narrow Unicode" builds; the result is a pair of UTF-16 surrogates.
This commit is contained in:
Amaury Forgeot d'Arc 2008-07-04 21:26:43 +00:00
parent 142957ce95
commit a4db68622c
4 changed files with 43 additions and 27 deletions

View file

@ -294,21 +294,12 @@ do_mkvalue(const char **p_format, va_list *p_va, int flags)
case 'C':
{
int i = va_arg(*p_va, int);
Py_UNICODE c;
if (i < 0 || i > PyUnicode_GetMax()) {
#ifdef Py_UNICODE_WIDE
PyErr_SetString(PyExc_OverflowError,
"%c arg not in range(0x110000) "
"(wide Python build)");
#else
PyErr_SetString(PyExc_OverflowError,
"%c arg not in range(0x10000) "
"(narrow Python build)");
#endif
"%c arg not in range(0x110000)";
return NULL;
}
c = i;
return PyUnicode_FromUnicode(&c, 1);
return PyUnicode_FromOrdinal(i);
}
case 's':