This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] Y2038: add struct __timespec64
- From: Joseph Myers <joseph at codesourcery dot com>
- To: "Albert ARIBAUD (3ADEV)" <albert dot aribaud at 3adev dot fr>
- Cc: <libc-alpha at sourceware dot org>
- Date: Wed, 19 Sep 2018 13:12:08 +0000
- Subject: Re: [PATCH] Y2038: add struct __timespec64
- References: <email@example.com>
On Wed, 19 Sep 2018, Albert ARIBAUD (3ADEV) wrote:
> diff --git a/time/bits/types/struct_timespec64.h b/time/bits/types/struct_timespec64.h
> new file mode 100644
> index 0000000000..2221bed8bc
> --- /dev/null
> +++ b/time/bits/types/struct_timespec64.h
Since it's actually defining struct __timespec64, the header needs to be
bits/types/struct___timespec64.h. bits/types/struct_timespec64.h would
define a type struct timespec64, but we don't have such a type.
> +/* Y2036proof structure for a time value. This is like a `struct timeval' but
> + has nanoseconds instead of microseconds. To keep tings Posix-ish, we keep
> + the nanoseconds field a signed long, but since Linux has a 64-bit signed int,
> + we pad it with a 32-bit int, which should always be 0.
> + Note that the public type has an anonymous bitfield as padding, so that
> + it cannot be written into (or read from). */
The bit-fields needs to be *anonymous* for initializers to work as
intended. It can't have the name tv_pad that it has in this patch, or any
other name, with our without leading underscores.
> +#if BYTE_ORDER == BIG_ENDIAN
These macros are in the user namespace. You have to use __BYTE_ORDER /
> +struct __timespec64
> + __time64_t tv_sec; /* Seconds */
> + int tv_pad: 32; /* Padding named for checking/setting */
> + __syscall_slong_t tv_nsec; /* Nanoseconds */
You also need a separate x86 version of the header that avoids inserting
the padding for x32, given the (nonconforming) 64-bit __syscall_slong_t
there. Then, the wrapper in include/ will be wrong for x86, so the
generic one probably needs to move from time/ to the top-level bits/
directory so the correct header is found in all cases.
Joseph S. Myers