This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Fwd: Fifth draft of the Y2038 design document
On Thu, 2 Mar 2017, Arnd Bergmann wrote:
> > I do expect the functions that use times internally but not in their
> > interface to be able to be changed to use 64-bit-time interfaces
> > unconditionally, and for this to work on an old kernel. (Whether this is
> > needed for calls to e.g. __xstat64 if times aren't actually used from the
> > resulting structure would depend on what __xstat64 does with too-large
> > timestamps; if the kernel saturates them, a change may not strictly be
> > needed, but if EOVERFLOW errors occur then a change would be needed. And
> > given the desire to support kernels with 32-bit-time syscalls disabled, a
> > change to such calls is probably desirable in any case.)
>
> The idea for stat is that:
>
> - The old 'stat/utimes' syscalls get modified to do correct saturation for both
> file-system specific limits and 32-bit time_t limits.
So random calls to __xstat64 in glibc in code that doesn't use the time
parts of the result wouldn't need changing for that code to work with
files with post-2038 timestamps - but would need changing to use
__xstat64_time64 if we want them to work with kernels that disable the old
syscalls (and if __xstat64 continues to use the old syscalls).
> - The newly added (as of linux-4.12) statx() syscall gets used as the
> replacement for the entire stat family of syscalls with 64-bit time_t.
Does that then become the only stat-family syscall provided for all new
architectures added in 4.12 and later?
--
Joseph S. Myers
joseph@codesourcery.com