This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC v6 03/23] time: Add a timeval with a long tv_sec and tv_usec
- From: Alistair Francis <alistair23 at gmail dot com>
- To: Lukasz Majewski <lukma at denx dot de>
- Cc: Alistair Francis <alistair dot francis at wdc dot com>, GNU C Library <libc-alpha at sourceware dot org>, Arnd Bergmann <arnd at arndb dot de>, Florian Weimer <fweimer at redhat dot com>, Joseph Myers <joseph at codesourcery dot com>, Palmer Dabbelt <palmerdabbelt at google dot com>, "Maciej W. Rozycki" <macro at wdc dot com>, Zong Li <zongbox at gmail dot com>, Adhemerval Zanella <adhemerval dot zanella at linaro dot org>, Zack Weinberg <zackw at panix dot com>
- Date: Wed, 15 Jan 2020 15:15:02 +1000
- Subject: Re: [RFC v6 03/23] time: Add a timeval with a long tv_sec and tv_usec
- References: <cover.1578824547.git.alistair.francis@wdc.com> <85291ec316dcd3f3a3155488a8c290298650dc77.1578824547.git.alistair.francis@wdc.com> <20200114111651.48a7d4f7@jawa>
On Tue, Jan 14, 2020 at 8:17 PM Lukasz Majewski <lukma@denx.de> wrote:
>
> Hi Alistair,
>
> > On y2038 safe 32-bit systems the Linux kernel expects itimerval to
> > use a 32-bit time_t, even though the other time_t's are 64-bit. To
> > address this let's add a timeval_long
> ^^^^^^^^^^^^^ - I'm not so seasoned glibc
> developer, but I think that the _long suffix
> is a bit misleading.
>
> Maybe it would be more readable to name it as struct
> __timeval32 ? In that way one can see from the outset that we
> operate on 32 bit values.
It isn't explicitly 32-bit, it's just always a long which is why I
went with long in the name instead.
I'm happy to change the name, it doesn't really matter too much as
it's only user internally.
I'll wait to see what others think before changing it.
Alistair
>
> Community feedback is welcome :-)
>
> > struct to be used internally.
> > ---
> > include/time.h | 29 +++++++++++++++++++++++++++++
> > time/bits/types/struct_timeval.h | 8 ++++++++
> > 2 files changed, 37 insertions(+)
> >
> > diff --git a/include/time.h b/include/time.h
> > index e5e8246eac..201342d1ca 100644
> > --- a/include/time.h
> > +++ b/include/time.h
> > @@ -310,6 +310,35 @@ valid_timespec64_to_timeval (const struct
> > __timespec64 ts64) return tv;
> > }
> >
> > +/* Conversion functions for converting to/from __timeval_long
> > +. If the seconds field of a __timeval_long would
> > + overflow, they write { INT32_MAX, 999999 } to the output. */
> > +static inline struct timeval
> > +valid_timeval_long_to_timeval64 (const struct __timeval_long tv)
> > +{
> > + return (struct timeval) { tv.tv_sec, tv.tv_usec };
> > +}
> > +
> > +static inline struct __timeval_long
> > +valid_timeval64_to_timeval_long (const struct timeval tv64)
> > +{
> > + if (__glibc_unlikely (tv64.tv_sec > (time_t) 2147483647))
> > + return (struct __timeval_long) { 2147483647, 999999};
> > + return (struct __timeval_long) { tv64.tv_sec, tv64.tv_usec };
> > +}
> > +
> > +static inline struct timespec
> > +valid_timeval_long_to_timespec (const struct __timeval_long tv)
> > +{
> > + return (struct timespec) { tv.tv_sec, tv.tv_usec * 1000 };
> > +}
> > +
> > +static inline struct __timeval_long
> > +valid_timespec_to_timeval_long (const struct timespec ts)
> > +{
> > + return (struct __timeval_long) { (time_t) ts.tv_sec, ts.tv_nsec /
> > 1000 }; +}
> > +
> > /* Check if a value is in the valid nanoseconds range. Return true if
> > it is, false otherwise. */
> > static inline bool
> > diff --git a/time/bits/types/struct_timeval.h
> > b/time/bits/types/struct_timeval.h index 70394ce886..73697689cc 100644
> > --- a/time/bits/types/struct_timeval.h
> > +++ b/time/bits/types/struct_timeval.h
> > @@ -10,4 +10,12 @@ struct timeval
> > __time_t tv_sec; /* Seconds. */
> > __suseconds_t tv_usec; /* Microseconds. */
> > };
> > +
> > +/* A version of 'struct timeval' with `long` time_t
> > + and suseconds_t. */
> > +struct __timeval_long
> > +{
> > + long tv_sec; /* Seconds. */
> > + long tv_usec; /* Microseconds. */
> > +};
> > #endif
>
> 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