On 27.08.2026 17:19, Tom Tromey wrote:
>>>>>> "Jan" == Jan Dubiec <jdx@o2.pl> writes:
> 
> Jan> So I think the best solution is to use a sorting algorithm known to be
> Jan> stable on every host, e.g. the insertion sort implementation from my
> Jan> previous message.
> 
> Would it be possible to change the comparison function to be stable?

It is impossible by definition, because stability is a property of the 
sorting algorithm, not the comparator. However, the comparator can be 
modified in such a way that an unstable sorting algorithm produces a 
“good enough” result.

That said, the following simple patch is sufficient:
    /* Secondarily sort based on the first opcode nibble.  */
-  return p1->data.nib[0] - p2->data.nib[0];
+  if (p1->data.nib[0] != p2->data.nib[0])
+    return p1->data.nib[0] - p2->data.nib[0];
+
+  /* The 3rd sort key */
+  return strcmp(p1->name, p2->name);

However, I decided to take the longer route (see the attached patch) in 
order to make the opcode table as close as possible to the one that 
would be produced by a stable sorting algorithm.

> I think it would be somewhat nicer not to have a separate sort
> implementation.
> 
> If that's too hard, though, I think your approach is fine.
It wasn't difficult, but I’m still inclined to favor a stable, 
predictable sorting algorithm. That said, it’s not a big deal to me. Let 
me know what you think about it, and then I’ll post a new version of the 
patch.

/J.D.