about summary refs log tree commit diff
path: root/time/tst-itimer.c
Commit message (Collapse)AuthorAgeFilesLines
* Update copyright dates with scripts/update-copyrightsJoseph Myers2023-01-061-1/+1
|
* Update copyright dates with scripts/update-copyrightsPaul Eggert2022-01-011-1/+1
| | | | | | | | | | | | | | | | | | | | | | | I used these shell commands: ../glibc/scripts/update-copyrights $PWD/../gnulib/build-aux/update-copyright (cd ../glibc && git commit -am"[this commit message]") and then ignored the output, which consisted lines saying "FOO: warning: copyright statement not found" for each of 7061 files FOO. I then removed trailing white space from math/tgmath.h, support/tst-support-open-dev-null-range.c, and sysdeps/x86_64/multiarch/strlen-vec.S, to work around the following obscure pre-commit check failure diagnostics from Savannah. I don't know why I run into these diagnostics whereas others evidently do not. remote: *** 912-#endif remote: *** 913: remote: *** 914- remote: *** error: lines with trailing whitespace found ... remote: *** error: sysdeps/unix/sysv/linux/statx_cp.c: trailing lines
* time: Ignore interval nanoseconds on tst-itimerAdhemerval Zanella2021-10-041-9/+10
| | | | | | | | | | | | | Running the test on a 4.4 kernel within KVM, the precision used on ITIMER_VIRTUAL and ITIMER_PROF seems to different than the one used for ITIMER_REAL (it seems the same used for CLOCK_REALTIME_COARSE and CLOCK_MONOTONIC_COARSE). I did not see it on other kernels, for instance 5.11 and 4.15. To avoid trying to guess the resolution used, do not check the nanosecond internal values for the specific timers. Checked on i686-linux-gnu with a 4.4 kernel.
* time: Fix compile error in itimer test affecting hurdStafford Horne2021-09-161-2/+3
| | | | | | | | | | | | | | | | | | | | | The recent change to use __KERNEL_OLD_TIMEVAL_MATCHES_TIMEVAL64 to avoid doing 64-bit checks on some platforms broke the test for hurd where __KERNEL_OLD_TIMEVAL_MATCHES_TIMEVAL64 is not defined. With error: tst-itimer.c: In function 'do_test': tst-itimer.c:103:11: error: '__KERNEL_OLD_TIMEVAL_MATCHES_TIMEVAL64' undeclared (first use in this function) 103 | if (__KERNEL_OLD_TIMEVAL_MATCHES_TIMEVAL64) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ tst-itimer.c:103:11: note: each undeclared identifier is reported only once for each function it appears in Define a support helper to detect when setitimer and getitimer support 64-bit time_t. Fixes commit 6e8a0aac2f ("time: Fix overflow itimer tests on 32-bit systems"). Cc: Adhemerval Zanella <adhemerval.zanella@linaro.org> Cc: Joseph Myers <joseph@codesourcery.com>
* time: Fix overflow itimer tests on 32-bit systemsStafford Horne2021-08-151-2/+2
| | | | | | | | | | | | | | | | | | | | On the port of OpenRISC I am working on and it appears the rv32 port we have sets __TIMESIZE == 64 && __WORDSIZE == 32. This causes the size of time_t to be 8 bytes, but the tv_sec in the kernel is still 32-bit causing truncation. The truncations are unavoidable on these systems so skip the testing/failures by guarding with __KERNEL_OLD_TIMEVAL_MATCHES_TIMEVAL64. Also, futher in the tests and in other parts of code checking for time_t overflow does not work on 32-bit systems when time_t is 64-bit. As suggested by Adhemerval, update the in_time_t_range function to assume 32-bits by using int32_t. This also brings in the header for stdint.h so we can update other usages of __int32_t to int32_t as suggested by Adhemerval. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* time: Add getitimer and setitimer basic testsAdhemerval Zanella2021-04-151-0/+175
Checked on i686-linux-gnu and x86_64-linux-gnu. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>