Comment 16 for bug 1322784

So, flags_qsort expects begin to be the first index and end to be 1 greater than the last index. (It thus does more work than needed on one element arrays.) During the loop it maintains the invariants that all values in the range [begin + 1, l) are less than pivot and all values in [r, end) are greater than pivot. These ranges both might be empty. It exits the loop when l == r, which ensures that l is always a valid index; r might be equal to end and thus not a valid index.

Then, after the loop, l is set to one less than r. If begin + 1 == end, then l == begin and r == end, since the while loop was never entered.

So the code of flag_qsort itself looks ok to me, or at least if there's a problem, I haven't seen it. It seems somewhat unlikely for the compiler to misoptimize.

The caller that matters is HashMgr::load_tables, which uses an allocation made in decode_flags, which does the allocation and gives the caller both the pointer and he length, so it looks like it's passing the right size as well.

Integer overflow seems somewhat unlikely, although I suppose it's possible.

I really wish the crash reports had at least line number information.