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 belopolsky
Recipients belopolsky, georg.brandl, jcea, lemburg, mark.dickinson, ncoghlan, pitrou
Date 2011-02-23.15:15:30
SpamBayes Score 1.3772317e-13
Marked as misclassified No
Message-id <1298474131.25.0.33633579283.issue11286@psf.upfronthosting.co.za>
In-reply-to
Content
Antoine is right, my patch is only of "discussion" quality and if my approach gets support, I will produce a more polished patch.

While I am fairly certain that this bug should be fixed where it was introduced, namely in the _pickle module, I am not sure patching both load_binstring() and load_short_binstring() is the right approach.

It may be better to modify _Unpickler_Read() so that it returns self->input_buffer (or even self->input_buffer + self->next_read_idx) for zero n.  This would be a cleaner design similar to that for PyMem_Malloc() et al. (Since _Unpickler_Read() is private API and the comment documenting it does not specify that it returns NULL for n = 0, I think this can be done in a bugfix release.  Furthermore, I reviewed the uses of _Unpickler_Read() with variable and thus potentially zero size and one of them is followed by a null check for s.)

On the other hand, my patch also eliminates redundant call to _Unpickler_Read() and makes load_binstring() and load_short_binstring() logic similar to that in load_counted_long().  The main advantage, of course is skipping PyUnicode_Decode() which will load a codec potentially triggering an import and execution of python code.
History
Date User Action Args
2011-02-23 15:15:31belopolskysetrecipients: + belopolsky, lemburg, georg.brandl, jcea, mark.dickinson, ncoghlan, pitrou
2011-02-23 15:15:31belopolskysetmessageid: <1298474131.25.0.33633579283.issue11286@psf.upfronthosting.co.za>
2011-02-23 15:15:30belopolskylinkissue11286 messages
2011-02-23 15:15:30belopolskycreate