This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC 1/7] y2038: Introduce struct __timespec64
On Thu, 28 Mar 2019, Paul Eggert wrote:
> > There should not, however, be a public interface time64_t
> Yes, and that's why the two cases are not consistent. We're planning to
> do time_t differently: we are not attempting to support mixed-mode user
> code, so there is no need to export either __time64_t or time64_t to
> user code.
I'm not convinced that the absence of one set of interfaces (public time64
functions, time64_t, etc.) is a reason for inconsistency relating to a
piece of internals that is present in both cases (__time_t, __off_t,
etc.). I think having __time_t handled differently from __off_t in that
regard (by making the definition depend on _TIME_BITS, rather than only
having the definition of time_t depend on _TIME_BITS) would be liable to
confuse people reading glibc headers.
It's more plausible that the headers should not define __time_t at all in
the _TIME_BITS=64 case (if there are no interfaces that would use it).
--
Joseph S. Myers
joseph@codesourcery.com