[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*
>*"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