glibc 2.29: Reminder, only ~3 weeks to freeze!

[Zack Weinberg]

On Tue, Dec 18, 2018 at 2:34 PM Albert ARIBAUD <albert.aribaud@3adev.fr> wrote:
>
> But what about existing user code which calls public glibc interfaces
> which deal with struct timeval? So far there is the assumption that
> time-related user source code which compiles with 32-bit time should
> compile with 64-bit time without modification. Would we break this and
> not "port" existing struct timeval based public interfaces from 32- to
> 64-bit time?

I think it would be best to shim as many of the timeval-using APIs as
possible, even if they're obsolescent or even removed in POSIX.  Most
of them should be no problem to shim in user space; the only exception
I can think of, off the top of my head, is setitimer, because its
interaction with execve is different than timer_create+timer_settime.
(Specifically, a CPU time limit installed with
setitimer(ITIMER_VIRTUAL, ...) will survive execve, but if you do the
same thing with timer_create+timer_settime, it won't.)

zw