[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