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