RFC: strategies to provide y2038 support for stat functions
Florian Weimer
fweimer@redhat.com
Tue Jul 14 17:06:41 GMT 2020
* Adhemerval Zanella via Libc-alpha:
> Another possibility which would also require some plumbing is to:
>
> 1. Move the extensible stat function to compat symbols
>
> 2. Implement the stat family function as proper versioned symbols
> 2.1. Add the required libc_hidden_def and call the internal calls to
> avoid internal plts.
>
> 3. Implement the y2038 support as other symbols:
> 3.1. Add struct __stat_time64 and __stat64_time64
> 3.2. Add __stat_time64 and __stat64_time64
> 3.3. Implement stat by calling __stat_time64 and covert the output.
>
> A drawback is add new glibc symbols for stat, stat64, lstat, lstat64,
> fstat, fstat64, fstatat, fstatat64. In the other hand we can cleanup the
> stat struct and use a default one for all architectures and also cleanup
> the implementation to just use statx or fstatat64 syscall.
>
> I am more inclined on second way, so we could move away from the stat
> non_shared wrapper.
I agreed. It would be nice if we could get rid of all statically linked
C code for shared objects, for an easier bootstrap GCC procedure.
Thanks,
Florian
More information about the Libc-alpha
mailing list