Re: Revisiting 64-bit time_t

[Rich Felker <dalias@libc.org>]

On Mon, Jul 01, 2019 at 11:12:20PM +0200, Arnd Bergmann wrote:
> > > > Aside from community feedback, what's needed to make this possible, if
> > > > it's going to happen, is some good analysis of the scope of breakage.
> > > > Such analysis would also benefit glibc -- it would help determine how
> > > > safe their _TIME_BITS=64 option will be and whether it can be turned
> > > > on safely by default in the presence of old libraries built without
> > > > it. I've already discussed this casually with a few people and it
> > > > looks like the right starting point would be getting a Debian system
> > > > (Debian because their repo is utterly huge) with ALL library packages
> > > > installed and grepping /usr/include for all headers that involve
> > > > time_t or any of the derived types. Then, manual analysis would need
> > > > to be done to determine whether the usage actually has an impact.
> > >
> > > Yes, this is also one of the things we eventually plan to do in Linaro,
> > > but have not actually started.
> >
> > Would it be possible to prioritize starting this? It would be a big
> > help to deciding what direction we should take in musl and make this
> > move forward a lot quicker, I think. I was thinking we'd have to do it
> > ourselves or find someone else to convince to do it, but if Linaro
> > already plans to do this anyway, we could perhaps accelerate things
> > with no overall increase in effort to be spent.
> 
> I've had a first look here now, with a scripted search in /usr/include
> for all packages in debian testing/main:
> 
> apt-file search /usr/include | cut -f 1 -d: | uniq |
> while read i ; do
>     mkdir -p ${i}
>     cd ${i}
>     if [ ! -e "${i}_.*.deb" ] ; then
>         apt-get download ${i}
>     fi
>     FILE=${i}_*.deb
>     dpkg-deb --fsys-tarfile ${FILE} | tar xf - ./usr/include
>     cd ..
>     ctags -f - -R ${i}/ | grep
> '\<time_t\|timespec\|timeval\|struct.stat\|struct.rusage\>' >
> ${i}.tags
>     grep -r '\<time_t\|timespec\|timeval\|struct.stat\|struct.rusage\>'
> ${i}/ > ${i}.files
>     rm -rf ./${i}
> done
> 
> There are 4288 packages that provide a file in /usr/include, and out of those,
> 973 match the regular expression above, see the list at
> 
> https://pastebin.com/Yu22pLqQ
> 
> This took a few hours to run and could be done faster by running bits
> in parallel.
> I can send you the full output, but it's at 300kb compressed, it's a bit large
> for the mailing list. The regex also wasn't great, so I'm sure there
> are lots of false positives and negatives, but its' a start.

OK. That sounds like a lot, but upon looking, a lot of them look like
"libraries" whose main/sole consumer is a single application. So maybe
it's not so bad.

Rich