Message82910
loewis> Furthermore, all other uses of the "c" code might
loewis> need to be reconsidered.
$ grep 'BuildValue.*"c"' */*c
Modules/_cursesmodule.c: return Py_BuildValue("c", rtn);
Modules/mmapmodule.c: return Py_BuildValue("c", value);
$ grep '_Parse[^"]\+"[^":;]*c' */*c
Modules/mmapmodule.c: if (!PyArg_ParseTuple(args, "c:write_byte",
&value))
PC/msvcrtmodule.c: if (!PyArg_ParseTuple(args, "c:putch", &ch))
PC/msvcrtmodule.c: if (!PyArg_ParseTuple(args, "c:ungetch", &ch))
So we have:
* mmap.read_byte()->char, mmap.write_byte(char): should be fixed to
use bytes
* <curses window>.getkey()->char: it looks correct because the
function uses also "return PyUnicode_FromString(...);"
* msvcrt.putch(char), msvcrt.ungetch(char): msvcrt has also:
- msvcrt.getch()->byte string of 1 byte
- msvcrt.getwch()->unicode string of 1 character
- msvcrt.putwch(unicode string of 1 character)
- msvcrt_ungetwch(unicode string of 1 character)
Hum, putch(), ungetch(), getch() use inconsistent types
(unicode/bytes) and should be fixed. Another issue should be open for
that.
Notes: msvcrt.putwch() accepts string of length > 1 and
msvcrt.ungetwch() doesn't check string length (and so may crash with
length=0 or length > 1?). |
|
Date |
User |
Action |
Args |
2009-02-28 14:39:43 | vstinner | set | recipients:
+ vstinner, loewis, ocean-city |
2009-02-28 14:39:43 | vstinner | set | messageid: <1235831983.34.0.463662882096.issue5391@psf.upfronthosting.co.za> |
2009-02-28 14:39:42 | vstinner | link | issue5391 messages |
2009-02-28 14:39:41 | vstinner | create | |
|