Re: MS-Windows build of Grep [2/4]

[Jim Meyering]

Eli Zaretskii wrote:
>> From: Jim Meyering <address@hidden>
>> Cc: address@hidden,  address@hidden,  address@hidden
>> 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.