[Python-Dev] int vs ssize_t in unicode (original) (raw)
"Martin v. Löwis" martin at v.loewis.de
Thu Apr 13 10:06:21 CEST 2006
- Previous message: [Python-Dev] int vs ssize_t in unicode
- Next message: [Python-Dev] int vs ssize_t in unicode
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Neal Norwitz wrote:
I just grepped for INTMAX and there's a ton of them still (well 83 in /.c). Some aren't an issue like posixmodule.c, those are SCINTMAX. marshal is probably ok, but all uses should be verified. Really all uses of {INT,LONG}{MIN,MAX} should be verified and converted to PYSSIZET{MIN,MAX} as appropriate.
I replaced all the trivial ones; the remaining ones are (IMO) more involved, or correct. In particular:
- collectionsmodule: deque is still restricted to 2GiB elements
- cPickle: pickling does not support huge strings (and probably shouldn't); likewise marshal
- _sre is still limited to INT_MAX completely
- not sure why the mbcs codec is restricted to INT_MAX; somebody should check the Win64 API whether the restriction can be removed (most likely, it can)
- PyObject_CallFunction must be duplicated for PY_SSIZE_T_CLEAN, then exceptions.c can be extended.
Regards, Martin
- Previous message: [Python-Dev] int vs ssize_t in unicode
- Next message: [Python-Dev] int vs ssize_t in unicode
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]