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