Paul Eggert wrote:
> > No, this is not what you installed now.
>
> Yeouch, this is getting embarrassing. Should be fixed now.
Thanks.
Now, maybe we can discuss how to make this code more maintainable.
I agree that the EOVERFLOW case of stat(), lstat(), fstatat() is a
can of worms that is better avoided.
* The patch handles some stat(), lstat(), fstatat() calls, but not
all of them. What is the general answer to avoid EOVERFLOW?
- Regarding 32-bit off_t, we have the 'largefile' module,
which basically all packages that use Gnulib should be using.
- Regarding 32-bit ino_t, 32-bit binaries on Linux/x86 and
Linux/x86_64 are being phased out (also because of time_t
issues and Y2038).
- Other circumstances that can produce EOVERFLOW, according
to linux/fs/stat.c:
st_dev field too small.
st_rdev field too small.
st_nlink field too small.
st_size too large.
* Maintainability: What we have here effectively is a function
with 3 possible outcomes:
- file is a symlink.
- file is not a symlink.
- there was an error determining whether file is a symlink.
How about creating an (inline) function which represents this
logic in a more understandable way. Such as
int symlinkp (const char *file);
which returns
1 for a symlink,
0 for not a symlink,
-1 with errno set, in case of error.
* More generally, is it still true that returning a subset of a
'struct stat' is cheaper for the kernel than returning the
entire 'struct stat'. Would it make sense to have a function
like 'xstat' [1] in Gnulib?
Bruno
[1] https://lwn.net/Articles/394298/
