[Bug 12091] Direct use of __NR_clock_gettime is not time64-safe

[bugzilla at busybox.net]

https://bugs.busybox.net/show_bug.cgi?id=12091

--- Comment #2 from bugdal at aerifal.cx ---
Commits 902d399292 and b7b7452f29 attempted to fix this, but the fix is
glibc-dependent (uses internal glibc macro __TIMESIZE) and breaks the ability
for time64-ready binaries to run on older kernels that lack the time64
syscalls.

I would really like to see this fixed by dropping the whole raw syscall hack
and using the public clock_gettime function. This would also enable use of vdso
clock_gettime. For ancient glibc (and possibly uclibc?) it needs -lrt, but that
could be handled with trylink like -lcrypt, -lm, etc. are now.

If this is unacceptable, I can prepare a patch to fix the above issues. It
would condition the time64 code path on sizeof(time_t) rather than __TIMESIZE
and would in that case use __NR_clock_gettime64 if it's defined, falling back
if it's not defined or if it fails with ENOSYS (older kernels) to
__NR_clock_gettime and converting the results if sizeof(long)<sizeof(time_t).

As the code stands now, it is going to break on all 32-bit archs with the next
release of musl.

-- 
You are receiving this mail because:
You are on the CC list for the bug.