diff options
author | Rich Felker <dalias@aerifal.cx> | 2019-07-31 00:26:16 -0400 |
---|---|---|
committer | Rich Felker <dalias@aerifal.cx> | 2019-08-02 00:08:23 -0400 |
commit | 72f50245d018af0c31b38dec83c557a4e5dd1ea8 (patch) | |
tree | 1ccfc1efb5564d4240d3feb542a89d0e2e93b70c /src/time/ctime.c | |
parent | 2b4fd6f75b4fa66d28cddcf165ad48e8fda486d1 (diff) | |
download | musl-72f50245d018af0c31b38dec83c557a4e5dd1ea8.tar.gz musl-72f50245d018af0c31b38dec83c557a4e5dd1ea8.tar.xz musl-72f50245d018af0c31b38dec83c557a4e5dd1ea8.zip |
clock_gettime: add time64 syscall support, decouple 32-bit time_t
the time64 syscall has to be used if time_t is 64-bit, since there's no way of knowing before making a syscall whether the result will fit in 32 bits, and the 32-bit syscalls do not report overflow as an error. on 64-bit archs, there is no change to the code after preprocessing. on current 32-bit archs, the result is now read from the kernel through long[2] array, then copied into the timespec, to remove the assumption that time_t is the same as long. vdso clock_gettime is still used in place of a syscall if available. 32-bit archs with 64-bit time_t must use the time64 version of the vdso function; if it's not available, performance will significantly suffer. support for both vdso functions could be added, but would break the ability to move a long-lived process from a pre-time64 kernel to one that can outlast Y2038 with checkpoint/resume, at least without added hacks to identify that the 32-bit function is no longer usable and stop using it (e.g. by seeing negative tv_sec). this possibility may be explored in future work on the function.
Diffstat (limited to 'src/time/ctime.c')
0 files changed, 0 insertions, 0 deletions