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 Paul, Joseph, > >> However, as long as __time64_t and __time_t are not visible to user > >> code when _TIME_BITS=64, this will address most of my own practical > >> concerns and should be OK as a compromise. > > > > To sum up: > > ---------- > > > > 1. __time64_t and __time_t are "exported" (visible > > in /usr/include/*) always (similar to __off_t and __off64_t). > > No, the compromise is that these types are "exported" only when > _TIME_BITS<64. Exporting them when _TIME_BITS==64 is unnecessary and > confusing. (It's also unnecessary and confusing when _TIME_BITS<64, > but I'm willing to compromise there because the _TIME_BITS<64 case is > obsolescent and will eventually go away.) > > > 2. The "exported" struct timespec would look like: > > > > struct timespec > > { > > /* Use the original definition for 64-bit arches > > or when 64-bit-time by default has *not* been requested */ > > #if __WORDSIZE > 32 || ! defined(__USE_TIME_BITS64) > > __time_t tv_sec; /* Seconds. */ > > #else > > __time64_t tv_sec; > > #end > > __syscall_slong_t tv_nsec; > > }; > > Sorry, I'm not following this. Why can't this be the natural 'struct > timespec { time_t tv_sec; ...; }'? The two forms are equivalent, > regardless of whether __WORDSIZE > 32 || ! defined(__USE_TIME_BITS64) > and regardless of what we do about (1), so why use the > more-complicated and more-confusing definition? Ok, time_t shall be used for tv_sec. > > As Joseph mentioned, there may need to be ifdeffery around tv_nsec > due to the issue of endian-dependent padding around tv_nsec. It is not only the padding. The problem is with the size of this struct passed to the kernel as syscall. 1. __TIMESIZE = 64 -> No problem with kernel ABI - sizeof(tv_sec) = 64 bit - sizeof(tv_nsec) = 64 bit Kernel looks for tv_sec and tv_nsec, each 64 bit 2. __TIMESIZE = 32 (no, Y2038 support) -> No problem with kernel ABI - sizeof(tv_sec) = 32 bit - sizeof(tv_nsec) = 32 bit Kernel looks for tv_sec and tv_nsec, each 32 bit (those syscalls would be removed from the kernel) 3. __TIMESIZE = 32 (Y2038 support) -> ABI problem - sizeof(tv_sec) = 64 bit (time_t) - sizeof(tv_nsec) = 32 bit - needed padding (tv_pad) 32 bit Kernel expects tv_sec and tv_nsec to be both 64 bits. Exported (installed at /usr/include) struct timespec (to work in above three cases): struct timespec { time_t tv_sec; /* Seconds. */ #ifdef __USE_TIME_BITS64 # if BYTE_ORDER == BIG_ENDIAN int tv_pad: 32; /* Padding named for checking/setting */ __syscall_slong_t tv_nsec; /* Nanoseconds */ # else __syscall_slong_t tv_nsec; /* Nanoseconds */ int tv_pad: 32; /* Padding named for checking/setting */ # endif #else __syscall_slong_t tv_nsec; /* Nanoseconds. */ #endif }; and internal (in ./include/time.h) definition of struct __timespec64: #if __TIMESIZE == 64 # define __timespec64 timespec #else struct __timespec64 { __time64_t tv_sec; /* Seconds */ __time64_t tv_nsec; /* Nanoseconds */ }; #endif > However, > there does not need to be ifdeffery around tv_sec. Just use time_t > there; problem solved. > > > 3. Put the internal struct __timespec64 ... > > into include/time.h and don't introduce separate > > include/bits/types/struct___timespec64.h > > > > The same idea would be applied to struct timeval > > Yes. 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:
pgp6oxs5RIV3_.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] |