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 Andreas,
> On Feb 12 2020, Lukasz Majewski wrote:
>
> > I've added the struct __timespec64 definition to
> > ./include/bits/struct/timespec.h
> >
> >
> > and I had build errors on ./include/time.h which uses struct
> > __timespec64 massively.
> > It requires explicit adding of #include
> > <include/bits/struct/timespec.h> or <bits/struct/timespec.h>
>
Apparently I had wrong paths.
> This works for me:
>
> diff --git a/include/bits/types/struct_timespec.h
> b/include/bits/types/struct_timespec.h index c27417cfd5..de1cf44311
> 100644 --- a/include/bits/types/struct_timespec.h
> +++ b/include/bits/types/struct_timespec.h
The question is about naming convention -
include/bits/types/struct_timespec.h -> suggest that we do have here
the "internal" re-definition of struct timespec but IMHO we do
introduce another "internal type" - namely struct __timespec64
Hence the below code shall be put to:
include/bits/types/struct__timespec64.h
to have the distinction between internally used struct timespec and
struct __timespec64 (which would be used explicitly on archs with
__WORDSIZE==32 (e.g. arm32, rv32)
Am I right here?
> @@ -1 +1,30 @@
> +#ifndef _STRUCT_TIMESPEC
> #include <time/bits/types/struct_timespec.h>
> +
> +#ifndef _ISOMAC
> +# include <endian.h>
> +# if __TIMESIZE == 64
> +# define __timespec64 timespec
> +# else
> +/* The glibc Y2038-proof struct __timespec64 structure for a time
> value.
> + To keep things Posix-ish, we keep the nanoseconds field a 32-bit
> + signed long, but since the Linux field is a 64-bit signed int, we
> + pad our tv_nsec with a 32-bit unnamed bit-field padding.
> +
> + As a general rule the Linux kernel is ignoring upper 32 bits of
> + tv_nsec field. */
> +struct __timespec64
> +{
> + __time64_t tv_sec; /* Seconds */
> +# if BYTE_ORDER == BIG_ENDIAN
> + __int32_t :32; /* Padding */
> + __int32_t tv_nsec; /* Nanoseconds */
> +# else
> + __int32_t tv_nsec; /* Nanoseconds */
> + __int32_t :32; /* Padding */
> +# endif
> +};
> +# endif
> +#endif
> +
> +#endif
> diff --git a/include/time.h b/include/time.h
> index 73f66277ac..f806bd8f0f 100644
> --- a/include/time.h
> +++ b/include/time.h
> @@ -6,7 +6,6 @@
> # include <bits/types/locale_t.h>
> # include <stdbool.h>
> # include <time/mktime-internal.h>
> -# include <endian.h>
> # include <time-clockid.h>
> # include <sys/time.h>
>
> @@ -60,29 +59,6 @@ extern void __tzset_parse_tz (const char *tz)
> attribute_hidden; extern void __tz_compute (__time64_t timer, struct
> tm *tm, int use_localtime) __THROW attribute_hidden;
>
> -#if __TIMESIZE == 64
> -# define __timespec64 timespec
> -#else
> -/* The glibc Y2038-proof struct __timespec64 structure for a time
> value.
> - To keep things Posix-ish, we keep the nanoseconds field a 32-bit
> - signed long, but since the Linux field is a 64-bit signed int, we
> - pad our tv_nsec with a 32-bit unnamed bit-field padding.
> -
> - As a general rule the Linux kernel is ignoring upper 32 bits of
> - tv_nsec field. */
> -struct __timespec64
> -{
> - __time64_t tv_sec; /* Seconds */
> -# if BYTE_ORDER == BIG_ENDIAN
> - __int32_t :32; /* Padding */
> - __int32_t tv_nsec; /* Nanoseconds */
> -# else
> - __int32_t tv_nsec; /* Nanoseconds */
> - __int32_t :32; /* Padding */
> -# endif
> -};
> -#endif
> -
> #if __TIMESIZE == 64
> # define __itimerspec64 itimerspec
> #else
>
> Andreas.
>
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:
pgpC06UOxSdg8.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] |