[RFC 1/7] y2038: Introduce struct __timespec64
Lukasz Majewski
lukma@denx.de
Mon Apr 1 05:30:00 GMT 2019
Hi Paul,
> >> However, as long as __time64_t and __time_t are not visible to user
> >> code when _TIME_BITS=64, this will address most of my own practical
> >> concerns and should be OK as a compromise.
> >
> > To sum up:
> > ----------
> >
> > 1. __time64_t and __time_t are "exported" (visible
> > in /usr/include/*) always (similar to __off_t and __off64_t).
>
> No, the compromise is that these types are "exported" only when
> _TIME_BITS<64. Exporting them when _TIME_BITS==64 is unnecessary and
> confusing. (It's also unnecessary and confusing when _TIME_BITS<64,
> but I'm willing to compromise there because the _TIME_BITS<64 case is
> obsolescent and will eventually go away.)
Ok. As __time64_t has been "hidden" in your previous mktime patch set,
I suppose that this would be changed in the next version?
>
> > 2. The "exported" struct timespec would look like:
> >
> > struct timespec
> > {
> > /* Use the original definition for 64-bit arches
> > or when 64-bit-time by default has *not* been requested */
> > #if __WORDSIZE > 32 || ! defined(__USE_TIME_BITS64)
> > __time_t tv_sec; /* Seconds. */
> > #else
> > __time64_t tv_sec;
> > #end
> > __syscall_slong_t tv_nsec;
> > };
>
> Sorry, I'm not following this. Why can't this be the natural 'struct
> timespec { time_t tv_sec; ...; }'? The two forms are equivalent,
> regardless of whether __WORDSIZE > 32 || ! defined(__USE_TIME_BITS64)
> and regardless of what we do about (1), so why use the
> more-complicated and more-confusing definition?
Currently there is __time_t tv_sec, so I've followed the pattern.
I don't mind to change it to time_t tv_sec.
>
> As Joseph mentioned, there may need to be ifdeffery around tv_nsec
> due to the issue of endian-dependent padding around tv_nsec.
I thought that we may only be concerned about endiannes on the
"internal" (i.e. struct __timespec64) representation, which would be
passed as the argument to Linux syscalls.
> However,
> there does not need to be ifdeffery around tv_sec. Just use time_t
> there; problem solved.
Ok.
>
> > 3. Put the internal struct __timespec64 ...
> > into include/time.h and don't introduce separate
> > include/bits/types/struct___timespec64.h
> >
> > The same idea would be applied to struct timeval
>
> Yes.
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20190401/191daf79/attachment.sig>
More information about the Libc-alpha
mailing list