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 v4 07/24] time: Deprecate struct timezone members


On Mon, Aug 12, 2019 at 8:53 PM Paul Eggert <eggert@cs.ucla.edu> wrote:
> Joseph Myers wrote:
> > it might mean that these two functions are exceptions to the
> > general rule of functions for 32-bit time being thin wrappers round their
> > 64-bit counterparts.
>
> If I'm understanding you correctly, you're suggesting that the existing-ABI
> get/settimeofday calls behave as before (albeit with __attribute_deprecated__
> warnings at compile-time), whereas the new-ABI gettimeofday clears *TZ if TZ is
> nonnull and the new-ABI settimeofday ignores TZ.

This is also what I understand Joseph to be suggesting.

> That way, the one or two
> ancient apps that rely on this stuff will still work if compiled in 32-bit
> time_t mode. This sounds like a good way to go forward.

However, I don't agree with this assessment of it I think it would be
confusing, and potentially a source of bugs that only affect less
popular architectures, if new-ABI and old-ABI gettimeofday don't treat
the TZ argument the same.  And I suspect that any "ancient apps" are
actually mishandling time zones and we'd be doing them a favor by
making them think they're operating in UTC from now on.

(systemd's use of the timezone argument to settimeofday is a separate issue.)

> It might also make sense for the new-ABI gettimeofday to simply ignore its TZ
> argument, as that would be easier to document and explain (plus a bit faster for
> the typical gettimeofday case).

That's not safe; callers that pass a non-NULL TZ argument to
gettimeofday may well rely on it writing _something_ there.  If it
doesn't, they'll be operating on stack garbage.


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