This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients serhiy.storchaka, steve.dower, vstinner
Date 2016-09-19.08:44:12
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CAMpsgwZSLW_fEQb_OYxoZzKwtum9g3hS6cybbAybgkwUXtEHYg@mail.gmail.com>
In-reply-to <1474257699.65.0.655254933642.issue28200@psf.upfronthosting.co.za>
Content
Steve Dower added the comment:
> It's not clear to me that Py_UNICODE is guaranteed to be wchar_t for all time, that's all. If it is, go ahead.

Right now, it's the case and path_converter() leaks memory, so I
proposed a simple and obvious fix :-)

On Windows, it makes sense to continue to use the UTF-16 encoded
string cached in Unicode objects, because this conversion is common,
and it's convenient to not have to release the memory explicitly. The
side effect is that we may waste memory in some cases.

> Otherwise the path_t object has the ability to clean up after itself, so perhaps it should be used here?

Maybe, but I'm not interested to write a more complex patch for
Windows :-) Try to just call PyMem_Free(path->wide) (do nothing it's
NULL).

The advantage of the old code (and my patch) is to only convert a
filename once to UTF-16 and then use the cached result.
History
Date User Action Args
2016-09-19 08:44:13vstinnersetrecipients: + vstinner, serhiy.storchaka, steve.dower
2016-09-19 08:44:12vstinnerlinkissue28200 messages
2016-09-19 08:44:12vstinnercreate