Walter Dörwald wal...@livinglogic.de added the comment:
On 24.02.10 15:28, Eric Smith wrote:
Eric Smith e...@trueblade.com added the comment:
Fixed:
trunk: r78418
release26-maint: r78419
Still working on porting to py3k and release31-maint.
A much better solution would IMHO be to
Eric Smith e...@trueblade.com added the comment:
A much better solution would IMHO be to forbid setting the encoding,
object and reason attributes to objects of the wrong type in the first
place. Unfortunately this would require an extension to PyMemberDef for
the T_OBJECT and T_OBJECT_EX
Walter Dörwald wal...@livinglogic.de added the comment:
I'm not sure what the functions should do when start and end are
out of range.
I think the best approach would be to prevent these values to be out of
range in the first place.
The start and end values should be clipped, just like
Eric Smith e...@trueblade.com added the comment:
Thanks, Walter. I'll finish my patch, then.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7309
___
Ezio Melotti ezio.melo...@gmail.com added the comment:
I'm not sure what the functions should do when start and end are
out of range.
I think the best approach would be to prevent these values to be out of
range in the first place.
All the args should be checked when the instance is created
Eric Smith e...@trueblade.com added the comment:
I agree there's not much value in making the attributes read/write, but
it looks like all of the exceptions allow it, so I don't really want to
make these exceptions the only ones that are different.
--
Trundle andy-pyt...@hammerhartes.de added the comment:
Crashes reliable with a segfault in Python 3.1.1.
Fixing the setter so that one can only set strings and not arbitrary
objects is possibly the best solution.
--
nosy: +Trundle
versions: +Python 3.1
Eric Smith e...@trueblade.com added the comment:
I'm not sure why reason should be restricted to a string. This patch
(against trunk) just converts reason to a string when str() is called.
I'll add tests and fix the other places in exceptions.c where similar
shortcuts are taken without checking,
Eric Smith e...@trueblade.com added the comment:
Actually attach the patch.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7309
___
___
Eric Smith e...@trueblade.com added the comment:
One more time with the patch attachment.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7309
___
Changes by Eric Smith e...@trueblade.com:
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7309
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Smith e...@trueblade.com:
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7309
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric Smith e...@trueblade.com added the comment:
For some reason I'm not able to attach the patch file. I'll look at
that, but in the meantime here's the preliminary patch against trunk:
Index: Objects/exceptions.c
===
---
Ezio Melotti ezio.melo...@gmail.com added the comment:
Note that on Py2.6, when, for example, a string is assigned to u.start
and u.end a TypeError is raised, and the value is then set to -1:
u=UnicodeTranslateError(u'x', 1, 5, 'bah')
u.start = 'foo'
Traceback (most recent call last):
File
Eric Smith e...@trueblade.com added the comment:
The patch that is (hopefully) attached is a first, incomplete cut just
for demonstration purposes. I still need to cover all of the cases where
PyString_AS_STRING are called without type checking. Also, as Ezio
points out, start and end are used
Changes by Eric Smith e...@trueblade.com:
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7309
___
___
Python-bugs-list mailing list
Unsubscribe:
Ezio Melotti ezio.melo...@gmail.com added the comment:
The same problem (u.start and u.end) also affects the other UnicodeError
exceptions (namely UnicodeEncodeError and UnicodeDecodeError).
Py2.4 and 2.5 don't seem to segfault with the example I provided.
--
Eric Smith e...@trueblade.com added the comment:
Another patch against trunk which deals with:
UnicodeEncodeError: reason and encoding
UnicodeDecodeError: reason and encoding
UnicodeTranslateError: reason
Still needs tests. Also, the unchecked use of start and end needs to be
addressed. I'm
Changes by Eric Smith e...@trueblade.com:
Removed file: http://bugs.python.org/file15331/issue7309.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7309
___
Changes by Eric Smith e...@trueblade.com:
Added file: http://bugs.python.org/file15337/issue7309-1.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7309
___
Changes by Eric Smith e...@trueblade.com:
Removed file: http://bugs.python.org/file15336/issue7309.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7309
___
Eric Smith e...@trueblade.com added the comment:
Tests need to cover issues like:
# assigning a non-string to e.object
e = UnicodeDecodeError(, , 0, 1, )
e.object = None
print str(e)
# start and end out of range
e = UnicodeDecodeError(, , 0, 1, )
e.start = 1000
e.end = 1001
print str(e)
For
Ezio Melotti ezio.melo...@gmail.com added the comment:
I don't know if this is a real problem. If someone who want to crash
someone else program is able to do something like 'u.reason =
somethingweird' there are already more serious problems to solve.
I don't see why someone would want to do
Ezio Melotti ezio.melo...@gmail.com added the comment:
After further investigations I found out that PyString_AS_STRING() is
the macro form of PyString_AsString() but without error checking (so
there's nothing to fix there, possibly just replace that call with
PyString_AsString if it turns out
New submission from Armin Rigo ar...@users.sourceforge.net:
The __str__ method of some exception classes reads attributes without
typechecking them. Alternatively, the issue could be that the user is
allowed to set the value of these attributes directly, without
typecheck. The typechecking is
25 matches
Mail list logo
