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] | |
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 struct to be used internally.
^^^^^^^^^^ - I think that this shall be
updated.
> ---
> include/time.h | 43 +++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 43 insertions(+)
>
> diff --git a/include/time.h b/include/time.h
> index d425c69ede..c2c05bb671 100644
> --- a/include/time.h
> +++ b/include/time.h
> @@ -388,6 +388,49 @@ timespec64_to_timeval64 (const struct
> __timespec64 ts64) return tv64;
> }
>
> +/* A version of 'struct timeval' with `long` time_t
> + and suseconds_t. */
> +struct __timeval32
> +{
> + long tv_sec; /* Seconds. */
As __timeval32 will be used in e.g __setitimer64 (which in turn will be
aliased to setitimer on archs with __WORDSIZE==64 && __TIMESIZE==64)
long seems to be the best option as it will be 64 bits for those
machines.
For ones with __WORDSIZE==32 it will be 32 bits instead. Am I correct?
> + long tv_usec; /* Microseconds. */
> +};
> +
> +/* Conversion functions for converting to/from __timeval32
> +. If the seconds field of a __timeval32 would
> + overflow, they write { INT32_MAX, 999999 } to the output. */
> +static inline struct __timeval64
> +valid_timeval32_to_timeval64 (const struct __timeval32 tv)
> +{
> + return (struct __timeval64) { tv.tv_sec, tv.tv_usec };
> +}
> +
> +static inline struct __timeval32
> +valid_timeval64_to_timeval32 (const struct __timeval64 tv64)
> +{
> + if (__glibc_unlikely (tv64.tv_sec > (time_t) 2147483647))
> + return (struct __timeval32) { 2147483647, 999999};
What is the purpose of this code?
The valid_* prefix shall indicate that the timeval64 will fit the
timeval32 and there is no need for any explicit check.
I would expect usage of this function as presented here:
https://patchwork.ozlabs.org/patch/1230884/
if (! in_time_t_range (tv64.tv_sec))
{
__set_errno (EOVERFLOW);
return -1;
}
if (tv)
*tv = valid_timeval64_to_timeval (tv64);
> + return (struct __timeval32) { tv64.tv_sec, tv64.tv_usec };
> +}
> +
> +static inline struct timeval
> +valid_timeval32_to_timeval (const struct __timeval32 tv)
> +{
> + return (struct timeval) { tv.tv_sec, tv.tv_usec };
> +}
> +
> +static inline struct timespec
> +valid_timeval32_to_timespec (const struct __timeval32 tv)
> +{
> + return (struct timespec) { tv.tv_sec, tv.tv_usec * 1000 };
> +}
> +
> +static inline struct __timeval32
> +valid_timespec_to_timeval32 (const struct timespec ts)
> +{
> + return (struct __timeval32) { (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
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
Attachment:
pgpt3QIoYaSUM.pgp
Description: OpenPGP digital signature
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |