This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug manual/20524] strverscmp is inconsistent
- From: "peda at lysator dot liu.se" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Mon, 29 Aug 2016 11:44:12 +0000
- Subject: [Bug manual/20524] strverscmp is inconsistent
- Auto-submitted: auto-generated
- References: <bug-20524-131@http.sourceware.org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=20524
--- Comment #4 from Peter Rosin <peda at lysator dot liu.se> ---
To expand on that, in case there is any doubt...
Quoting the docs
Basically, we compare strings normally (byte by byte), until we find a
digit in each string - then we enter a special comparison mode, where
each sequence of digits is taken as a whole.
This fundamental property of the comparison is not consistent with
observed behavior, since the comparison is affected by what is after
the whole sequences of digits.
I.e. strverscmp has this ordering for some strings with leading 00:
0000 < 0001 < 000 < 000! < 000a < 001 < 00 < 00! < 00a
This does not agree with common sence (0001 and 001 are too early, they
should be last), but at least strings with the same sequences of digits
are sorted together. But if you then change that to leading 01, it gets
completely unreasonable:
01 < 01! < 010 < 010! < 0100 < 0101 < 010a < 011 < 01a
Here 0100 and 0101 weasels in between 010! and 010a. And there is a
boatload of crap between 01! and 01a. 01, 01! and 01a should be right
next to each other, and so should 010, 010! and 010a. Anything else
is fundamentally broken.
strverscmp is simply not considering the whole sequences of digits,
which is brutally obvious when the result of the comparison is
affected by what is after the digits. Which also means that strverscmp
is not comparing fractions, it is doing something else entirely.
--
You are receiving this mail because:
You are on the CC list for the bug.