Message151899
I took a deep dive into parts of CPython that were unknown to me :) and dug up the following:
Methods like os.stat or even os.open convert the file name using "et" in PyArg_ParseTuple[AndKeywords].
OTOH, open() and io.open() just hand through the object as "O" to the respective low-level io module.
The result in 2.7 is that file() tries to convert it for it's own usage eventually – which fails as seen. While a more explicit error message wouldn't hurt, this seems safe to me insofar.
In 3.3, file() aka Modules/_io/fileio.c , io_open does no such thing because it seems to handle fds as "nameobj" as well and does a wide range of checks on the argument.
After io_open is certain that nameobj is a file name, it uses PyObject_AsCharBuffer()on bytes and PyUnicode_FromObject() + encoding magic on unicode to get an encoded string as a file name.
Neither does a check for NUL bytes so the (w)open(er) that follows reacts as demonstrated by Antoine.
I presume fixing/breaking PyObject_AsCharBuffer()/PyUnicode_FromObject() is out of question so the most obvious part to fix would be the conversion block inside io_open.
Should I have a stab at it or do you disagree with my approach? |
|
Date |
User |
Action |
Args |
2012-01-24 12:55:32 | hynek | set | recipients:
+ hynek, pitrou, alex |
2012-01-24 12:55:32 | hynek | set | messageid: <1327409732.07.0.807798280175.issue13848@psf.upfronthosting.co.za> |
2012-01-24 12:55:31 | hynek | link | issue13848 messages |
2012-01-24 12:55:30 | hynek | create | |
|