New submission from Sebastian Hagen :
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 if used
in this manner
Sebastian Hagen 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 as unicode-except-not
Sebastian Hagen 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 conversion code
Sebastian Hagen 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 in current trunk.
Sebastian Hagen 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 migh
Sebastian Hagen 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 case; the byte
Sebastian Hagen 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] on linux2
Type "
New submission from Sebastian Hagen :
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] on linux2
Changes by Sebastian Hagen :
--
status: open -> closed
versions: -Python 3.2
___
Python tracker
<http://bugs.python.org/issue7560>
___
___
Python-bugs-list mai
Sebastian Hagen 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 that the sam
Sebastian Hagen 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
<http://bugs.python.
Changes by Sebastian Hagen :
Removed file: http://bugs.python.org/file15659/posix_fn_bytes_01.patch
___
Python tracker
<http://bugs.python.org/issue7560>
___
___
Pytho
Changes by Sebastian Hagen :
--
type: -> behavior
___
Python tracker
<http://bugs.python.org/issue7560>
___
___
Python-bugs-list mailing list
Unsubscri
New submission from Sebastian Hagen :
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- and pathnames ultim
New submission from Sebastian Hagen :
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')
Tracebac
15 matches
Mail list logo
