Antoine Pitrou pit...@free.fr added the comment:
Well, it should be backported to 2.6 first, then.
(which is not necessarily trivial since a lot of bug fixes in 3.0/3.1
weren't backported to the 2.6/2.7 io module, AFAIK)
--
resolution: - accepted
stage: needs patch - committed/rejected
R. David Murray rdmur...@bitdance.com added the comment:
Antoine, I added you to the nosy list for this because it turns out the
new io.c segfaults in this case.
--
keywords: -patch
nosy: +pitrou
___
Python tracker rep...@bugs.python.org
Antoine Pitrou pit...@free.fr added the comment:
The reason py3k is a lot longer to crash is because of a slight bug in
_fileio.c :-) I'm gonna correct this one first.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1174606
Antoine Pitrou pit...@free.fr added the comment:
A fix for py3k was committed in r70664.
--
versions: -Python 3.1
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1174606
___
R. David Murray rdmur...@bitdance.com added the comment:
Antoine, since your fix also goes into the io module in 2.6, and the
buggish behavior even of the old code is more cosmetic than problematic,
I'm thinking we can just close this as accepted. Do you concur?
--
R. David Murray rdmur...@bitdance.com added the comment:
I applied the patch against the trunk, and 'make' failed:
File /home/rdmurray/python/Issue1174606/Lib/platform.py, line 932,
in _syscmd_uname
output = string.strip(f.read())
OverflowError: requested number of bytes is more than
Dustin J. Mitchell [EMAIL PROTECTED] added the comment:
While it is a sensible fix for the signed/unsigned problem, David's patch
still fails regrtest on my system (amd64), after OOM-killing random other
processes :(
Andrew's suggestion makes a lot of sense here. Does it make sense for
Dustin J. Mitchell [EMAIL PROTECTED] added the comment:
Improved fix; this passes test_file on my system.
--
keywords: +patch
Added file: http://bugs.python.org/file10266/1174606.patch
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1174606
Adam Olsen [EMAIL PROTECTED] added the comment:
new_buffersize returns a size_t. You should use SIZE_MAX instead
(although I don't see it used elsewhere in CPython, so maybe there's
portability problems.)
The call to _PyString_Resize implicitly casts the size_t to Py_ssize_t.
The check
Adam Olsen [EMAIL PROTECTED] added the comment:
The indentation still needs tweaking. You have only one tab where you
should have two, and one line uses a mix of tabs and spaces.
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1174606
Dustin J. Mitchell [EMAIL PROTECTED] added the comment:
Ack, sorry. My 'vi' settings should now be correct.
Added file: http://bugs.python.org/file10274/1174606-3.patch
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1174606
David Chrsitian added the comment:
I don't see any change to the return value of new_buffersize that could
alleviate this problem - the problem being that because linux is
extremely efficient at reading bytes from /dev/zero, some other code
incosistencies are exposed.
The problem that is being
Changes by David Christian:
Added file: http://bugs.python.org/file9512/issue1174606.diff
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1174606
_
___
Python-bugs-list
A.M. Kuchling added the comment:
This seems like an easy fix: just check that S_ISREG(st_mode) is true in
new_buffersize in fileobject.c.
--
keywords: +easy
nosy: +akuchling
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1174606
14 matches
Mail list logo
