Re: Surprising behaviour with numeric glob sort

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Jun 4,  6:31pm, Stephane Chazelas wrote:
}
} "Slow" (though probably quite negligible compared to strcoll()
} which already does things like in addition to a lot more hard
} wark) but working.

According to one strcoll man page I have, the right thing to do is
convert all the strings with strxfrm and then strcmp those.

It provides no advice on how to order the original array to match the
sorted result of the xfrm'd array (the transform is not reversible),
nor how to determine how much space to allocate for each transform.

Zsh has the additional complication of needing to deal with strings
having embedded '\0' bytes, which neither strcoll nor strxfrm is able
to deal with.  I'm not 100% confident that zsh's current algorithm
deals correct with this either.

A possible approach would be to pre-allocate a hash table and fill
it on the fly with keys the original strings and values the strxfrm
results.  An additional strxfrm could be called on the trailing bits
after any embedded nul.  Then sort the original array by comparing
the values in the hash.  Doesn't solve the question of how much space
to reserve, but it would allow the current algorithm for picking out
numeric substrings to be used.

For parameter array sorting we could extend the (m) flag to indicate
that this transformation is required [it already means to count byte
widths for (l), (r), etc.] so as to avoid the overhead when it is not
needed.  For globbing, we'd have to rely on something else such as
whether MULTIBYTE is set.