[issue1950] Potential overflows due to incorrect usage of PyUnicode_AsString.

Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment: On 2008-05-03 20:25, Alexandre Vassalotti wrote: > Alexandre Vassalotti <[EMAIL PROTECTED]> added the comment: > > Committed to r62667. > > Thank you all for your comments! > > -- > resolution: -> fixed > status: open -> closed

[issue1950] Potential overflows due to incorrect usage of PyUnicode_AsString.

Alexandre Vassalotti <[EMAIL PROTECTED]> added the comment: Committed to r62667. Thank you all for your comments! -- resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> __

[issue1950] Potential overflows due to incorrect usage of PyUnicode_AsString.

Alexandre Vassalotti <[EMAIL PROTECTED]> added the comment: Marc-Andre Lemburg wrote: [SNIP] > The above cast needs to be (Py_ssize_t). size_t is an unsigned length type. Actually, the cast is right (even though it is not strictly necessary). It just the patch that is confusing. Here is the re

[issue1950] Potential overflows due to incorrect usage of PyUnicode_AsString.

Alexandre Vassalotti <[EMAIL PROTECTED]> added the comment: Alexander Belopolsky wrote: > The patch looks good. Just a question: I thought the strings returned > by PyUnicode_AsStringAndSize are 0-terminated, while your patch at > several places attempts to explicitly 0-terminate a copy of such

[issue1950] Potential overflows due to incorrect usage of PyUnicode_AsString.

Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment: BTW: The API PyUnicode_AsString() is pretty useless by itself - there's no way to access the size information of the returned string without again going to the Unicode object. I'd suggest to remove the API altogether and not only deprecat

[issue1950] Potential overflows due to incorrect usage of PyUnicode_AsString.

Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment: @@ -2195,7 +2200,7 @@ } return Py_None; } - len = lastdot - start; + len = (size_t)(lastdot - start);

[issue1950] Potential overflows due to incorrect usage of PyUnicode_AsString.

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment: The patch looks good. Just a question: I thought the strings returned by PyUnicode_AsStringAndSize are 0-terminated, while your patch at several places attempts to explicitly 0-terminate a copy of such string. Are you sure this is n

[issue1950] Potential overflows due to incorrect usage of PyUnicode_AsString.

Alexandre Vassalotti <[EMAIL PROTECTED]> added the comment: So, any comment on the latest patch? If everything is all right, I would like to commit the patch to py3k. __ Tracker <[EMAIL PROTECTED]> __

[issue1950] Potential overflows due to incorrect usage of PyUnicode_AsString.

Alexandre Vassalotti <[EMAIL PROTECTED]> added the comment: I revised the patch with respect to Alexander's comments. In summary, here is what I changed from the previous patch: - Removed the unnecessary "fixes" to Objects/structseq.c and Modules/timemodule.c - Updated Objects/typeobject

[issue1950] Potential overflows due to incorrect usage of PyUnicode_AsString.

Guido van Rossum <[EMAIL PROTECTED]> added the comment: Any progress? -- nosy: +gvanrossum __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-lis

[issue1950] Potential overflows due to incorrect usage of PyUnicode_AsString.

Alexandre Vassalotti <[EMAIL PROTECTED]> added the comment: Thanks for the review! > Your description of the patch is a bit misleading. As far as I can > tell only the first chunk (Python/import.c changes) addresses a > potential buffer overflow. Yes, you are right. It seems only the bug in im

[issue1950] Potential overflows due to incorrect usage of PyUnicode_AsString.

Alexander Belopolsky added the comment: Here are my comments on the other parts of the patch: Python/structmember.c The existing code is safe, but would silently produce wrong result if T_CHAR attribute is assigned a non-ascii character. With the patch this situation will be detected and an ex

[issue1950] Potential overflows due to incorrect usage of PyUnicode_AsString.

Alexander Belopolsky added the comment: I tried to produce a buffer overflow in get_parent (import.c), but an attempt to import a module with non-ascii characters is aborted in getargs.c before get_parent is reached: >>> __import__("\u0080xyz") Traceback (most recent call last): File "", line

[issue1950] Potential overflows due to incorrect usage of PyUnicode_AsString.

Alexander Belopolsky added the comment: Your description of the patch is a bit misleading. As far as I can tell only the first chunk (Python/import.c changes) addresses a potential buffer overflow. For example the last chunk (Modules/posixmodule.c changes) simply eliminates an unused variable.

[issue1950] Potential overflows due to incorrect usage of PyUnicode_AsString.

Changes by Alexandre Vassalotti: -- title: Potential Overflow due to incorrect usage of PyUnicode_AsString. -> Potential overflows due to incorrect usage of PyUnicode_AsString. __ Tracker <[EMAIL PROTECTED]> ___