bug#58168: string-lessp glitches and inconsistencies

[Mattias Engdegård]

6 okt. 2022 kl. 13.06 skrev Eli Zaretskii <eliz@gnu.org>:

> Cf. NaN comparisons with numerical values.

Emacs strings are completely different from floats and NaNs in just about every 
respect; no meaningful parallels can be drawn. (And do believe me when I say 
that we should be thankful for that.)

> You missed me here.  Why are you suddenly talking about mismatches?
> And if only mismatches matter here, why is it a problem to use memchr
> in the first place?

Any lexicographic comparison is a matter of finding the first point of 
difference, then interpreting the difference at that point. `memchr` does not 
help with that, nor does `memcmp` unless we are doing a bytewise string 
comparison.

I've pushed a further optimisation of the comparison between arbitrary 
multibyte strings; it's now sufficiently fast that I no longer worry much about 
it (on my machine asymptotically 10× faster than before, yet 30 % slower than 
memcmp).

Similar improvements could be made to the comparison between unibyte and 
non-ASCII multibyte strings. These are less common and not quite as slow; I 
haven't made up my mind about whether it's worth the trouble.

Again it's complicated by the equivalence between unibyte and Latin-1: it means 
that two equal strings can have different byte patterns, which in turn makes it 
much more expensive to find the longest common prefix. (Thus this point is of 
practical interest in several respects.)

In any case, the situation is now better than it was before the bug was opened: 
string< is faster and the remaining problems have at least been chartered, 
whether or not an agreement to remedy them can be reached. Let's be happy about 
this!