Eli Zaretskii wrote: >> From: Jim Meyering <[email protected]> >> Cc: [email protected], [email protected], [email protected] >> Date: Fri, 30 Dec 2011 13:38:17 +0100 >> >> This is about changing code that everyone uses, in order to >> make it accommodate a system that is so fundamentally deficient >> that imho it is not a reasonable portability target. > > Well, gnulib does support this "fundamentally deficient" system.
Not when it comes to code that (for safety) must be inode-aware. For example, see fts.c's uses fts-cycle.c. > Personally, I think that a utility macro such as SAME_INODE should > uphold its contract on all supported systems. But that's me; I'm not > a gnulib maintainer, so feel free to ignore me. > > In any case, as I already wrote, the change I suggested in SAME_INODE > is only a bonus: if no one cares about the code in Grep's main.c that > I think belongs to SAME_INODE, then no change is necessary, because > the code works as it is. > >> As long as its *stat functions (or wrappers) do not provide usable >> stat.st_ino, trying to accommodate such systems is a waste of time. > > How is the problem with st_ino on Windows different from what > SAME_REGULAR_FILE in src/system.h is trying to do to cope with all > kinds of very similar breakage in `struct stat' on Posix hosts? Without useful stat.st_ino, there are some important tasks (e.g., dir traversal) that simply cannot be performed safely/reliably.
