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: [PATCH 3/6] y2038: Introduce struct __timeval64 - new internal glibc type


On Mon, Jan 20, 2020 at 1:34 PM Lukasz Majewski <lukma@denx.de> wrote:
> > > On Sun, Jan 19, 2020 at 4:22 PM Lukasz Majewski <lukma@denx.de>
> > > wrote:
> > > > > On Sat, Jan 18, 2020 at 11:48 PM Alistair Francis <alistair23@gmail.com> wrote:
> > >
> > > It would certainly help if this could be consistent across
> > > architectures and libraries.
> >
> > Ok. Thanks for the input.
>
> Would it be OK to have:
>
> struct __timeval64
> {
>   __time64_t tv_sec;         /* Seconds */
>   __int64_t tv_usec;       /* Microseconds */
> };

This would not work if you pass it into a kernel interface that expects
a 32-bit suseconds_t on sparc64, but it should work as an internal
type on all 32-bit architectures.

> I would prefer to avoid changing typedef of suseconds_t as it may
> affect struct timeval related operations.
>
> Using explicitly __int64_t for tv_usec seems better option, isn't it?

Maybe a __suseconds64_t that happens to be 32-bit wide on sparc64?

     Arnd


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