[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190701220745.GY1506@brightrain.aerifal.cx>
Date: Mon, 1 Jul 2019 18:07:45 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Revisiting 64-bit time_t
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
