glibc/io/sys, branch master

Always define __USE_TIME_BITS64 when 64 bit time_t is used

2024-04-02T18:28:36Z

It was raised on libc-help [1] that some Linux kernel interfaces expect the libc to define __USE_TIME_BITS64 to indicate the time_t size for the kABI. Different than defined by the initial y2038 design document [2], the __USE_TIME_BITS64 is only defined for ABIs that support more than one time_t size (by defining the _TIME_BITS for each module). The 64 bit time_t redirects are now enabled using a different internal define (__USE_TIME64_REDIRECTS). There is no expected change in semantic or code generation. Checked on x86_64-linux-gnu, i686-linux-gnu, aarch64-linux-gnu, and arm-linux-gnueabi [1] https://sourceware.org/pipermail/libc-help/2024-January/006557.html [2] https://sourceware.org/glibc/wiki/Y2038ProofnessDesign Reviewed-by: DJ Delorie

Update copyright dates with scripts/update-copyrights

2024-01-01T18:53:40Z

y2038: Fix support for 64-bit time on legacy ABIs

2023-11-15T13:15:12Z

This fixes a typo. Reviewed-by: Adhemerval Zanella

Update copyright dates with scripts/update-copyrights

2023-01-06T21:14:39Z

Update copyright dates with scripts/update-copyrights

2022-01-01T19:40:24Z

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

Don't add access size hints to fortifiable functions

2021-10-20T03:03:31Z

In the context of a function definition, the size hints imply that the size of an object pointed to by one parameter is another parameter. This doesn't make sense for the fortified versions of the functions since that's the bit it's trying to validate. This is harmless with __builtin_object_size since it has fairly simple semantics when it comes to objects passed as function parameters. With __builtin_dynamic_object_size we could (as my patchset for gcc[1] already does) use the access attribute to determine the object size in the general case but it misleads the fortified functions. Basically the problem occurs when access attributes are present on regular functions that have inline fortified definitions to generate _chk variants; the attributes get inherited by these definitions, causing problems when analyzing them. For example with poll(fds, nfds, timeout), nfds is hinted using the __attr_access as being the size of fds. Now, when analyzing the inline function definition in bits/poll2.h, the compiler sees that nfds is the size of fds and tries to use that information in the function body. In _FORTIFY_SOURCE=3 case, where the object size could be a non-constant expression, this information results in the conclusion that nfds is the size of fds, which defeats the purpose of the implementation because we're trying to check here if nfds does indeed represent the size of fds. Hence for this case, it is best to not have the access attribute. With the attributes gone, the expression evaluation should get delayed until the function is actually inlined into its destinations. Disable the access attribute for fortified function inline functions when building at _FORTIFY_SOURCE=3 to make this work better. The access attributes remain for the _chk variants since they can be used by the compiler to warn when the caller is passing invalid arguments. [1] https://gcc.gnu.org/pipermail/gcc-patches/2021-October/581125.html Signed-off-by: Siddhesh Poyarekar

y2038: Add support for 64-bit time on legacy ABIs

2021-06-15T13:42:11Z

A new build flag, _TIME_BITS, enables the usage of the newer 64-bit time symbols for legacy ABI (where 32-bit time_t is default). The 64 bit time support is only enabled if LFS (_FILE_OFFSET_BITS=64) is also used. Different than LFS support, the y2038 symbols are added only for the required ABIs (armhf, csky, hppa, i386, m68k, microblaze, mips32, mips64-n32, nios2, powerpc32, sparc32, s390-32, and sh). The ABIs with 64-bit time support are unchanged, both for symbol and types redirection. On Linux the full 64-bit time support requires a minimum of kernel version v5.1. Otherwise, the 32-bit fallbacks are used and might results in error with overflow return code (EOVERFLOW). The i686-gnu does not yet support 64-bit time. This patch exports following rediretions to support 64-bit time: * libc: adjtime adjtimex clock_adjtime clock_getres clock_gettime clock_nanosleep clock_settime cnd_timedwait ctime ctime_r difftime fstat fstatat futimens futimes futimesat getitimer getrusage gettimeofday gmtime gmtime_r localtime localtime_r lstat_time lutimes mktime msgctl mtx_timedlock nanosleep nanosleep ntp_gettime ntp_gettimex ppoll pselec pselect pthread_clockjoin_np pthread_cond_clockwait pthread_cond_timedwait pthread_mutex_clocklock pthread_mutex_timedlock pthread_rwlock_clockrdlock pthread_rwlock_clockwrlock pthread_rwlock_timedrdlock pthread_rwlock_timedwrlock pthread_timedjoin_np recvmmsg sched_rr_get_interval select sem_clockwait semctl semtimedop sem_timedwait setitimer settimeofday shmctl sigtimedwait stat thrd_sleep time timegm timerfd_gettime timerfd_settime timespec_get utime utimensat utimes utimes wait3 wait4 * librt: aio_suspend mq_timedreceive mq_timedsend timer_gettime timer_settime * libanl: gai_suspend Reviewed-by: Lukasz Majewski Reviewed-by: Carlos O'Donell Tested-by: Carlos O'Donell

Annotate additional APIs with GCC attribute access.

2021-05-06T17:01:05Z

This change continues the improvements to compile-time out of bounds checking by decorating more APIs with either attribute access, or by explicitly providing the array bound in APIs such as tmpnam() that expect arrays of some minimum size as arguments. (The latter feature is new in GCC 11.) The only effects of the attribute and/or the array bound is to check and diagnose calls to the functions that fail to provide a sufficient number of elements, and the definitions of the functions that access elements outside the specified bounds. (There is no interplay with _FORTIFY_SOURCE here yet.) Tested with GCC 7 through 11 on x86_64-linux.

sys: Fixes possible typo in comment: statfs -> statvfs

2021-04-07T04:14:25Z

Update copyright dates with scripts/update-copyrights

2021-01-02T20:17:34Z

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 6694 files FOO. I then removed trailing white space from benchtests/bench-pthread-locks.c and iconvdata/tst-iconv-big5-hkscs-to-2ucs4.c, to work around this diagnostic from Savannah: remote: *** pre-commit check failed ... remote: *** error: lines with trailing whitespace found remote: error: hook declined to update refs/heads/master