This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Fri, Jul 26, 2019 at 9:01 AM Florian Weimer <fweimer@redhat.com> wrote:
>
> * Arnd Bergmann:
>
> > 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.
>
> Renaming the struct timezone members might be sufficient.  Then the code
> above would still compile, but something that actually depends on the
> struct timezone data would not.

I like this idea.  We could escalate to hiding the definition later.

zw


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]