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)
