[RFC v2 07/20] sysdeps/gettimeofday: Use clock_gettime64 if avaliable

Arnd Bergmann arnd@arndb.de
Thu Jul 25 18:53:00 GMT 2019


On Thu, Jul 25, 2019 at 7:21 PM Zack Weinberg <zackw@panix.com> wrote:
>
> On Thu, Jul 25, 2019 at 1:03 PM Paul Eggert <eggert@cs.ucla.edu> wrote:
> >
> > Arnd Bergmann wrote:
> > > If we want to keep
> > > the traditional settimeofday()/gettimeofday() behavior working, a new
> > > kernel interface could be added
> >
> > Let's not. That behavior was a bad idea even in the 1980s, and applications
> > stopped using it decades ago. It has been completely obsoleted by TZ strings.
>
> Do we think we could get away with having both functions fail (with
> EINVAL) whenever the tz argument is non-null?

>From my findings at Debian code search, I found code like

struct timeval my_gettime(void)
{
     struct timezone tz_ignored;
     struct timeval tv;
     gettimeofday(&tv, &tz_ignored);
     return tv;
}

In this case, the safer choice would be to silently ignore it.

Another alternative would be to hide the definition of 'struct timezone'
in the libc headers and only leave a forward declaration.

That would lead to a compile-time error here, and force a change in
any source code that actually tries to use the timezone in a
meaningful way.

We also need to deal with other compile-time failures for code that
is not y2038 safe (e.g. __NR_futex users), so this may be a reasonable
compromise.

       Arnd



More information about the Libc-alpha mailing list