filevercmp incompatible change?

[(GalaxyMaster)]

Hello,

[I am not subscribed, so please CC me if you need any further info]

I think the following commit introduced a behavioural change that was not
intended: 
https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=1ba2b66ea45f9bc43cdc0f6f93efa59157d2b2ba

coreutils 9.1 are supplied with the previous version of that file and passes
the following test (which relies on filevercmp()):
===
galaxy@apollo:~/ls-test $ ~/rpm-work/BUILD/coreutils-9.1/src/ls -v -A .A .Z .a 
.z .zz~ .zz .zz.~1~ .0 .9 .zz.0 0 9 A Z a z zz~ zz zz.~1~ zz.0 | cat
.A
.Z
.a
.z
.zz~
.zz
.zz.~1~
.0
.9
.zz.0
0
9
A
Z
a
z
zz~
zz
zz.~1~
zz.0
galaxy@apollo:~/ls-test $
===

if I simply replace the filevercmp.c in coreutil's source tree with the one
from GNU gnulib and rebuild ls, the order changes:
===
galaxy@apollo:~/ls-test $ ~/rpm-work/BUILD/coreutils-9.1/src/ls -v -A .A .Z .a 
.z .zz~ .zz .zz.~1~ .0 .9 .zz.0 0 9 A Z a z zz~ zz zz.~1~ zz.0 | cat
.0
.9
.A
.Z
.a
.z
.zz~
.zz
.zz.~1~
.zz.0
0
9
A
Z
a
z
zz~
zz
zz.~1~
zz.0
galaxy@apollo:~/ls-test $
===

I am not very familiar with the version sorting (which was promoted by Debian
and seems to be widely adopted), but I believe the current version in GNU
gnulib is not following it and also it is worth mentioning that the coreutils
test was crafted by hand, so the order of the first example seems to be the
expected one.

The difference between two versions is very subtle (I am only including the
chunk with the real change):
===
[galaxy@apollo lib]$ diff -puN filevercmp.c{.included,}
--- filevercmp.c.included       2022-04-08 21:22:26.000000000 +1000
+++ filevercmp.c        2023-01-29 01:34:51.381264202 +1100
@@ -36,20 +37,22 @@ static idx_t
 file_prefixlen (char const *s, ptrdiff_t *len)
 {
   size_t n = *len;  /* SIZE_MAX if N == -1.  */
+  idx_t prefixlen = 0;

-  for (idx_t i = 0; ; i++)
+  for (idx_t i = 0; ; )
     {
-      idx_t prefixlen = i;
-      while (i + 1 < n && s[i] == '.' && (c_isalpha (s[i + 1])
-                                          || s[i + 1] == '~'))
-        for (i += 2; i < n && (c_isalnum (s[i]) || s[i] == '~'); i++)
-          continue;
-
       if (*len < 0 ? !s[i] : i == n)
         {
           *len = i;
           return prefixlen;
         }
+
+      i++;
+      prefixlen = i;
+      while (i + 1 < n && s[i] == '.' && (c_isalpha (s[i + 1])
+                                          || s[i + 1] == '~'))
+        for (i += 2; i < n && (c_isalnum (s[i]) || s[i] == '~'); i++)
+          continue;
     }
 }

===

It seems that the order was re-arranged and this triggers a side-effect, IMHO.

-- 
(GM)