On 04/11/2018 02:58 PM, Bernhard Voelker wrote:
didn't you mean the '>' operator?
No, '==' should be right. I added the attached to try to explain this better. Thanks for the nudge.
>From 09ca545d5c0af8760ce27b1e9cbe300e64f73746 Mon Sep 17 00:00:00 2001 From: Paul Eggert <egg...@cs.ucla.edu> Date: Wed, 11 Apr 2018 16:27:03 -0700 Subject: [PATCH] fts: add comment * lib/fts.c (fts_build): Explain why ==, not >. See remark by Bernhard Voelker in: https://lists.gnu.org/r/bug-gnulib/2018-04/msg00041.html --- ChangeLog | 5 +++++ lib/fts.c | 6 +++++- 2 files changed, 10 insertions(+), 1 deletion(-) diff --git a/ChangeLog b/ChangeLog index 3702f75c1..f5752a217 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,10 @@ 2018-04-11 Paul Eggert <egg...@cs.ucla.edu> + fts: add comment + * lib/fts.c (fts_build): Explain why ==, not >. + See remark by Bernhard Voelker in: + https://lists.gnu.org/r/bug-gnulib/2018-04/msg00041.html + fts: fix bug in find across filesystems This fixes a bug I introduced last summer. Problem reported by Kamil Dudka in: diff --git a/lib/fts.c b/lib/fts.c index a26c6824a..d54351059 100644 --- a/lib/fts.c +++ b/lib/fts.c @@ -1597,7 +1597,11 @@ mem1: saved_errno = errno; /* If there are many entries, no sorting function has been specified, and this file system is of a type that may be slow with a large number of entries, arrange to sort the - directory entries on increasing inode numbers. */ + directory entries on increasing inode numbers. + + The NITEMS comparison uses ==, not >, because the test + needs to be tried at most once once, and NITEMS will exceed + the threshold after it is incremented below. */ if (nitems == _FTS_INODE_SORT_DIR_ENTRIES_THRESHOLD && !sp->fts_compar) sort_by_inode = dirent_inode_sort_may_be_useful (cur, dir_fd); -- 2.14.3
