On Tue, 25 Jul 2017, Kyrill Tkachov wrote:
> For the uses of this function the order when the bitpos is the same
> does not matter, I just wanted to avoid returning zero to avoid perturbations
> due to qsort.

But you can't stabilize qsort in that manner, in fact by making the comparator
invalid you achieve the opposite: making the output unpredictable, even with
respect to elements with different bitpos.

> IMO the right thing to do here to avoid the qsort checker errors is to break
> the tie between store_immediate_info objects with equal bitpos by using the
> sort_by_order heuristic i.e. something like "return (*tmp)->order -
> (*tmp2)->order;".  That should give well-behaved results as the order of two
> store_immediate_info objects is guaranteed not to be the same (otherwise
> something has gone wrong elsewhere).

Note that my patch in this subthread has been applied already, please submit
a separate patch if you want to add this stabilizing clause.

Alexander

Reply via email to