[issue8821] Range check on unicode repr

Changes by Serhiy Storchaka : -- resolution: -> works for me stage: -> committed/rejected status: pending -> closed ___ Python tracker ___ __

[issue8821] Range check on unicode repr

Changes by Serhiy Storchaka : -- status: open -> pending ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://

[issue8821] Range check on unicode repr

Serhiy Storchaka added the comment: You can accept the patch. You can reject the patch. It doesn't matter. -- ___ Python tracker ___ __

[issue8821] Range check on unicode repr

Ezio Melotti added the comment: Should this be closed then? -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: h

[issue8821] Range check on unicode repr

Serhiy Storchaka added the comment: This patch is not needed for 3.3+. And for 2.7 and 3.2 it actually doesn't fix any bug in the current code. -- nosy: +serhiy.storchaka versions: -Python 3.1 ___ Python tracker _

[issue8821] Range check on unicode repr

Matt Giuca added the comment: > I think that we have good reasons to not remove the NUL character. Please note: Nobody is suggesting that we remove the NUL character. I was merely suggesting that we don't rely on it where it is unnecessary. Returning to my original patch: If the code was usin

[issue8821] Range check on unicode repr

STINNER Victor added the comment: > Unicode objects are NUL-terminated, but only very external APIs > rely on this (e.g. code using the Windows Unicode API). All Py_UNICODE_str*() functions rely on the NUL character. They are useful when patching a function from bytes (char*) to unicode (PyUni

[issue8821] Range check on unicode repr

Alexander Belopolsky added the comment: [MAL] > * Unicode objects are NUL-terminated, but only very external APIs >rely on this (e.g. code using the Windows Unicode API). Please >don't make the code in unicodeobject.c itself rely on this >subtle detail. I would like to note that se

[issue8821] Range check on unicode repr

Changes by Terry J. Reedy : -- versions: -Python 2.6, Python 3.3 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue8821] Range check on unicode repr

Matt Giuca added the comment: OK, I finally had time to review this issue again. Firstly, granted the original fix broke a test case, shouldn't we figure out why it broke and fix it, rather than just revert the change and continue relying on this tenuous assumption? Surely it's best to have a

[issue8821] Range check on unicode repr

Antoine Pitrou added the comment: > But all that is off-topic for this ticket, since codecs > operate on Py_UNICODE* buffers together with a size parameter > and relying on those buffers being NUL-terminated is bound to > cause problems. That's right. Then perhaps a fixed patch can be uploaded,

[issue8821] Range check on unicode repr

Marc-Andre Lemburg added the comment: Antoine Pitrou wrote: > > Antoine Pitrou added the comment: > >> * Unicode objects are NUL-terminated, but only very external APIs >>rely on this (e.g. code using the Windows Unicode API). Please >>don't make the code in unicodeobject.c itself re

[issue8821] Range check on unicode repr

Changes by Ezio Melotti : -- nosy: +ezio.melotti ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyt

[issue8821] Range check on unicode repr

Antoine Pitrou added the comment: > * Unicode objects are NUL-terminated, but only very external APIs >rely on this (e.g. code using the Windows Unicode API). Please >don't make the code in unicodeobject.c itself rely on this >subtle detail. That's wishful thinking, don't you think

[issue8821] Range check on unicode repr

Changes by Marc-Andre Lemburg : -- resolution: fixed -> status: closed -> open ___ Python tracker ___ ___ Python-bugs-list mailing lis

[issue8821] Range check on unicode repr

Marc-Andre Lemburg added the comment: Antoine Pitrou wrote: > > Antoine Pitrou added the comment: > > Well, the patch was technically useless since, as mentioned, unicode strings > are terminated by a NUL character by design. There are two things to keep in mind: * Unicode objects are NUL

[issue8821] Range check on unicode repr

Georg Brandl added the comment: You're right. Reverted in r83444 and merging back, and I'll also remove the "XXX is this needed" from 2.7. -- status: open -> closed ___ Python tracker _

[issue8821] Range check on unicode repr

Antoine Pitrou added the comment: Well, the patch was technically useless since, as mentioned, unicode strings are terminated by a NUL character by design. Anyway, I now get the following error on the 2.7 branch. Perhaps it's related: ==

[issue8821] Range check on unicode repr

Georg Brandl added the comment: Applied in r83395. Thanks! -- nosy: +georg.brandl resolution: -> fixed status: open -> closed ___ Python tracker ___

[issue8821] Range check on unicode repr

New submission from Matt Giuca : In unicodeobject.c's unicodeescape_string, in UCS2 builds, if the last character of the string is the start of a UTF-16 surrogate pair (between '\ud800' and '\udfff'), there is a slight overrun problem. For example: >>> repr(u'abcd\ud800') Upon reading ch = 0x