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


* 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.

Thanks,
Florian


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