Re: Accelerating Y2038 glibc fixes

[Rich Felker <dalias at libc dot org>]

On Thu, Jul 18, 2019 at 09:20:48AM +0200, Lukasz Majewski wrote:
> > > > To answer Wolfgang Denk's original question, in my opinion, the
> > > > single most valuable thing for accelerating the time64 process
> > > > that third parties could contribute is detailed analysis of the
> > > > interfaces that will break.  
> > > 
> > > Such analysis is already done and available on glib'c wiki page
> > > [3].  
> > 
> > ...because there's no such analysis here. Such analysis is basically a
> > grep -r of /usr/include on a Debian system with *-dev installed,
> > combined with some automated analysis of what packages depend on each
> > matching package's library, then manual analysis to determine impact
> > (and in many cases, whether the lib is even a real lib that's used by
> > multiple programs rather than just by the program it ships with).
> > 
> > Arnd sent me a really preliminary grep like this a couple weeks ago,
> > but doing it right is going to take a lot more time.
> 
> Is this script available somewhere? I'm wondering if I could adapt it
> (and run) to meta-y2038?

See this thread: https://www.openwall.com/lists/musl/2019/07/02/2

Again, the point here is identifying libraries that have
time_t-derived structures as part of their public APIs, since that
means their *ABIs* are functions of how time_t is defined. There are
fairly many, but there's also good reason to believe that lots of them
aren't actually "public" in any meaningful sense.

Assuming the list is produced correctly and is complete, updating
these in sync with the apps (or other libs) that consume them avoids
any breakage, and is a much smaller task than replacing the whole
binary ecosystem all at once.

Rich