I wrote: > The advantage of using gnulib for things like fts is that findutils is not the only consumer, and we're very likely to notice issues with it even in weird corner cases.
I should explain that this advantage is strong enough that, following a multi-year period of parallel running, we replaced the hand-coded-for-find file system search algorithm in GNU find with gnulib's not-invented-here fts() implementation. One of the key reasons for retiring the old implementation was that it was explicitly recursive. You just can't afford to have one stack frame per directory-hierarchy level (and IIRC, oldfind had about 2, occupying about 80 bytes in total). beginning: https://git.savannah.gnu.org/cgit/findutils.git/commit/?id=f0759ab8db9cab16699fba45fa6117ef06620194 end: https://git.savannah.gnu.org/cgit/findutils.git/commit/?id=5768a03ddfb5e18b1682e339d6cdd24ff721c510 James. On Wed, May 15, 2024 at 11:53 PM James Youngman <ja...@youngman.org> wrote: > [I changed the subject line because this is quite a tangent from the > original thread] > > On Wed, May 15, 2024 at 7:50 PM Nikolaos Chatzikonstantinou < > nchatz...@gmail.com> wrote: > >> >> How about GNU does a call to arms for an alternative Rust >> implementation of its coreutils? There's still hungry Rust devs out >> there willing to write a lot of code to prove themselves. >> > > A Rust-based coreutils implementation would do nothing for find, since > it's not part of coreutils. In this email I'm mainly going to discuss > findutils. I'm not a maintainer of coreutils and can't speak for the folks > who are, really. Although I am a maintainer of findutils, I'm not the only > one, and so what I'm writing here is just a personal opinion, not the > response from the "findutils maintainer team" at all. > > I haven't looked at this for a long time, but when I did look at the > coreutils implementation, I was left with the impression that the team's > engineering trade-offs favoured using standard Rust library interfaces over > native operating system (i.e. FFI) interfaces. > > For security above all reasons, findutils has preferred native interfaces > and gnulib's implementations/wrappers. The advantage of using gnulib for > things like fts is that findutils is not the only consumer, and we're very > likely to notice issues with it even in weird corner cases. I find it a > bit hard to imagine a Rust-based implementation correctly implementing GNU > find's "-regex" without using gnulib as the regex implementation, for > example. > > Find in particular needs to be able to work correctly in odd situations > where even library implementers would often just shrug and say those cases > are not in-scope. For example, > > - Where the current directory is above the root directory "/" > - Where the current directory contains an infinite loop of hard links > - Where the file system being searched is an active target of symlink > race attacks > - Where the current user lacks the search permission for the current > directory (but does not lack read permission) > - Where the current user lacks the read permission for the current > directory (but does not lack search permission) > - Where entries in /etc/fstab exist for which a stat or statvfs call > will hang forever > > If a Rust-based-find team was serious about making a 100% drop-in > backward compatible find implementation that would prioritise working > securely and correctly on the GNU system over other considerations, then > there's a discussion worth having. > > Flipping back to coreutils for a moment, the Rust-coreutils folks are > aiming for feature compatibility, but that's not the same thing as being a > completely faithful drop-in replacement. Maintainers of GNU core tools > (not just coreutils, other things too) are very, very careful about > breaking their callers[*]. There are cases with find, for example, where > the deprecation-to-removal timeline is 5 years+ (example: -perm +...). > I'm struggling to imagine that the Rust coreutils folks will really buy > into this kind of approach. They're using Clap as the command-line parser > for example. Now, actually I like Clap and there are projects where I've > used it. But it's a stretch to imagine that it's going to parse arguments > in precisely the same way as getopt_long() in all cases. So I find it > hard to imagine that the two suites will ever be close enough in behaviour > for either team to consider them aligned. Though of course I can imagine > some (obviously not all: nothing is ever "all") distributions electing to > switch even without this kind of drop-in-replacement compatibility. > > [*] probably my most memorable mistake was in making `find . -name foo > -maxdepth 2` generate a warning message. A mistake even though the stdout > output is identical. > > Please don't get the idea though that I'm against Rust. I think that, > yes, new tools should often be written in it. But that's a very different > question from replacing an existing tool, because compatibility is a hard > problem. > > James. > >
