New submission from Sebastian Hagen sh_pyb...@memespace.net:
io.BytesIO().readinto() does not correctly handle the case of being called on a
BytesIO object that has been seeked past the end of its data. It consequently
ends up reading into unallocated memory, and (typically?) segfaulting
Sebastian Hagen sh_pyb...@memespace.net added the comment:
Not exactly. The last part fixes the second problem, which you get for
non-zero-length bytearrays. But without the first fix, zero-length
bytearrays still lead to a crash:
Python 3.2a0 (py3k:77001M, Dec 22 2009, 18:17:08)
[GCC 4.3.4
Sebastian Hagen sh_pyb...@memespace.net added the comment:
You're correct about PyUnicode_FSConverter(), which is why the very
first part of my patch fixes that function. Only fixing that one will
get rid of the segfaults, but also lead to incorrect error reporting for
the zero-length bytearray
Sebastian Hagen sh_pyb...@memespace.net added the comment:
Correction: Only fixing that one will
get rid of the segfaults ... well, for mkdir() on GNU/Linux, anyway.
POSIX.1-2008 doesn't specify what happens if you call mkdir() with a
NULL pointer, so I guess other conforming implementations
Sebastian Hagen sh_pyb...@memespace.net added the comment:
I've glanced at some of the other PyByteArray_AS_STRING() (and
PyByteArray_AsStr(), which inherits this behaviour) uses in the stdlib.
By far the heaviest user is bytearrayobject.c; aside from that, there's
by my count only 24 uses
Sebastian Hagen sh_pyb...@memespace.net added the comment:
Well, it doesn't *need* to accept them ... but it would certainly be
nice to have. If you've already got the filename in a bytearray object
for some reason, being able to pass it through directly saves you both a
copy and the explicit
Sebastian Hagen sh_pyb...@memespace.net added the comment:
Oh, and *forcing* use of the PEP 383 hack for such interfaces would
really be the Wrong Thing. Byte sequences are the natural (and most
efficient, and least prone to misunderstandings) way to store filenames
on a posix-like. Storing them
New submission from Sebastian Hagen sh_pyb...@memespace.net:
Most of the functions in Python's stdlib that take filename parameters
allow for those parameters to be buffer (such as bytes, bytearray,
memoryview) objects. This is useful for various reasons, among them that
on Posix-likes, file
Changes by Sebastian Hagen sh_pyb...@memespace.net:
--
type: - behavior
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7560
___
___
Python-bugs
Changes by Sebastian Hagen sh_pyb...@memespace.net:
Removed file: http://bugs.python.org/file15659/posix_fn_bytes_01.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7560
Sebastian Hagen sh_pyb...@memespace.net added the comment:
I'm taking that patch back. More testing would have been in order before
posting; sorry for that, will repost once I've got the obvious problems
worked out.
--
___
Python tracker rep
Sebastian Hagen sh_pyb...@memespace.net added the comment:
And further testing reveals that all of this has in fact already been
fixed in trunk. I assumed it hadn't been, because the code for at least
some of the relevant functions in Modules/_posixmodule.c is the same as
in 3.1.1; I didn't know
Changes by Sebastian Hagen sh_pyb...@memespace.net:
--
status: open - closed
versions: -Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7560
New submission from Sebastian Hagen sh_pyb...@memespace.net:
Various functions in the 'posix' module that take filename arguments
accept bytearray values for those arguments, and mishandle those objects
in a way that leads to segfaults.
Python 3.1 (r31:73572, Jul 23 2009, 23:41:26)
[GCC 4.3.3
New submission from Sebastian Hagen sh_pyb...@memespace.net:
In either python 3.0, bytes instances cannot be copied, and (even
trivial) bytes subclasses cannot be unpickled unless they explicitly
override __getnewargs__() or __reduce_ex__().
Copy problem:
import copy; copy.copy(b'foo
15 matches
Mail list logo
