Re: [Nmh-workers] Remaining ambiguities in sortm man page

[Ken Hornstein]

>What happens when date fields compare equal (ideally, file modification times
>would be used) or when file modification times are equal (ideally, original
>order will be used).
>
>Since qsort is used, I'm guessing that the answer to both questions, is
>"undefined".

It looks like ... in theory, you are correct.  From qsort(3):

     The algorithms implemented by qsort(), qsort_r(), and heapsort() are not
     stable; that is, if two members compare as equal, their order in the
     sorted array is undefined.  The mergesort() algorithm is stable.

But ... actually, it's more complicated than that.  The actual qsort compare
function used by sortm never returns equal.  Hah!  I didn't know that.  What
it actually does is this:

/*
 * sort on dates.
 */
static int
dsort (struct smsg **a, struct smsg **b)
{
    if ((*a)->s_clock < (*b)->s_clock)
        return (-1);
    else if ((*a)->s_clock > (*b)->s_clock)
        return (1);
    else if ((*a)->s_msg < (*b)->s_msg)
        return (-1);
    else
        return (1);
}

So ... if s_clock (the date of the message) is equal, it will fall down
to test s_msg. s_msg is the message number, and of course two message numbers
can't be the same.  As it turns out, if two dates are the same it will use
original order.

--Ken