On 8/12/25 10:41, Bruno Haible wrote:
- Regarding 32-bit off_t, we have the 'largefile' module,
which basically all packages that use Gnulib should be using.
Yes, these days 32-bit time_t is more of an issue than 32-bit off_t.
Gnulib's year2038 module doesn't require 32-bit time_t. Even
year2038-recommended can be overridden by the installer to get a 32-bit
time_t.
- 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).
My impression is that with the _TIME_BITS stuff in glibc 2.34 and later,
there is some movement to keep 32-bit code alive past 2038 on Linux/x86.
It'd have to have _TIME_BITS=64 though.
EOVERFLOW issues also come up in some macOS releases. I don't offhand
remember which ones. Presumably other originally-32-bit OSes too.
* 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.
By "file is not a symlink" do you mean "file is a non-symlink"? Many
callers want to know whether the directory entry is there. This could be
done by having 4 outcomes, or (probably better) by having "file does not
exist" in the "there was an error" category.
It might be useful to return an errno value when there was an 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?
I haven't measured that, and I don't know how true it is. However, I
assume the xstat stuff was done for a reason.
