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 dev_zzo
Recipients JohnLeitch, dev_zzo, serhiy.storchaka
Date 2015-06-22.15:23:41
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Attached please find a patch against the 2.7 branch. CPython built with the patch passes the tests from the test suite. Unfortunately, as there is not much control over memory allocation, there is no 100% reliable test case that would allow for reproducing the reported issue.

Some notes on the patch.

I have studied possible ways of fixing the issue narrowing them to two options; the approaches considered were:
a. Patch bytearray methods so they use stringlib's functions with respect to the corner case of out-of-bounds access on m = n.
b. Patch fastsearch() avoiding the out-of-bounds access on m = n completely.

Of these two, approach a is less "invasive" as changes, in theory, would be contained in bytearray() code only and should not affect any other code. Approach b fixes all possible cases, but affects other code not related to bytearray.

Upon closer studying of both bytearray and stringlib code, I discovered that it might be impossible to patch bytearray code only as stringlib contains a few methods that make use of the affected fastsearch() function, see e.g. stringlib_partition() as used in bytearray_partition(). If the approach of fixing bytearray specific code only would be chosen, I have to incorporate at least some of code following the fastsearch() call in stringlib_partition(). Similar considerations apply to other bytearray methods that make use of stringlib; the amount of code duplication varies. The end result is, I chose to patch fastsearch() instead.

Performance wise, the change incurs a small penalty due to one extra branch when m != n and brings considerable gain in (potentially rare) case when m = n.

I would appreciate if someone could test and review the patch.

NB. I stand corrected for the comment in msg245457 -- there is a note I missed in the C code. My sincere apologies to the author.
Date User Action Args
2015-06-22 15:23:42dev_zzosetrecipients: + dev_zzo, serhiy.storchaka, JohnLeitch
2015-06-22 15:23:42dev_zzosetmessageid: <>
2015-06-22 15:23:42dev_zzolinkissue24462 messages
2015-06-22 15:23:42dev_zzocreate