Re: Accelerating Y2038 glibc fixes

[Rich Felker <dalias@libc.org>]

On Thu, Jul 18, 2019 at 10:47:15AM -0400, Rich Felker wrote:
> On Wed, Jul 17, 2019 at 11:57:48PM +0200, Lukasz Majewski wrote:
> > Note:
> > 
> > [1] -
> > https://github.com/lmajewski/y2038_glibc/commits/Y2038-2.29-glibc-11-03-2019
> > 
> > [2] - https://github.com/lmajewski/y2038-tests
> > 
> > [3] -
> > https://sourceware.org/glibc/wiki/Y2038ProofnessDesign?highlight=%28y2038%29
> > 
> > [4] - https://github.com/lmajewski/meta-y2038/tree/master
> 
> Some findings here that need correction:
> 
> [1] is completely missing the sysvipc interfaces affected, and [3]
> fails to document them as affected because the structs are variadic
> arguments not declared ones. Fortunately, this means we can get away
> without actually replacing the functions, and instead define new
> command numbers to perform the translation. When doing this, glibc
> should follow musl and correct other bugs in these structs: for
> example, struct ipc_perm's mode field has the wrong type on some archs
> (short instead of mode_t; only makes a difference on big endian).

Another omission I found: ftw/nftw. They pass stat structures back to
a callback. If the time64 stat structures start with the old stat64
structure and just append the new timespecs to the end, no action is
required here for compatibility. This is what I'm leaning towards
doing in musl, but it doesn't seem to be what the above glibc branch
does. If glibc is going to completely redefine the stat structure for
time64, then new versions ftw and nftw are needed along with
redirections for them. There may be other interfaces like this too. I
seem to recall glibc having another nonstandard interface like ftw,
but it being broken and not even supporting _FILE_OFFSET_BITS=64
yet, so no idea what would happen to it...

Rich