RFC: strategies to provide y2038 support for stat functions

[Carlos O'Donell]

On 7/14/20 12:49 PM, Adhemerval Zanella via Libc-alpha wrote:
> 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.
> 
> Thoughts?

I think such a cleanup would be worthwhile.

We should document the changes in such a way that developers writing
interposes have an easy time of updating and we can circulate these notes
to ensure people know this change is coming.

Existing interposers may need to be updated, so we should have a clearly
documented final set of public functions that require additional
interposition to completely cover the API. I think such preloads as
fakeroot and guix's own relocation support may require that these interfaces
be effectively interposed.

Thank you for writing this up.

-- 
Cheers,
Carlos.