Author hynek
Recipients alex, hynek, pitrou
Date 2012-01-24.12:55:30
SpamBayes Score 3.27186e-10
Marked as misclassified No
Message-id <1327409732.07.0.807798280175.issue13848@psf.upfronthosting.co.za>
In-reply-to
Content
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?
History
Date User Action Args
2012-01-24 12:55:32hyneksetrecipients: + hynek, pitrou, alex
2012-01-24 12:55:32hyneksetmessageid: <1327409732.07.0.807798280175.issue13848@psf.upfronthosting.co.za>
2012-01-24 12:55:31hyneklinkissue13848 messages
2012-01-24 12:55:30hynekcreate