[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Ken Hornstein
Subject: Re: [Nmh-workers] Remaining ambiguities in sortm man page
Date: Wed, 19 Mar 2014 11:52:48 -0400

>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

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);
        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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]