This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug manual/20524] strverscmp is inconsistent

--- Comment #4 from Peter Rosin <peda at lysator dot> ---
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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]