The __sem_check_add_mapping internal stat calls fails with
EOVERFLOW if system time is larger than 32 bit.
It is a missing spot from 52a5fe70a2 fix to use 64 bit stat
internally.
Checked on x86_64-linux-gnu and i686-linux-gnu.
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
The symbols were moved using move-symbol-to-libc.py.
Both functions are moved at the same time because they depend
on internal functions in sysdeps/pthread/sem_routines.c, which
are moved in this commit as well. Additional hidden prototypes
are required to avoid check-localplt failures.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Take in consideration the trailling NULL since sem_search uses
strcmp to compare entries.
Checked on x86_64-linux-gnu and powerpc-linux-gnu (where it triggered
a nptl/tst-sem7 regression).
sem_open already returns EINVAL for input names larger than NAME_MAX,
so it can assume the largest name length with tfind.
Checked on x86_64-linux-gnu.
The internal semaphore list code is moved to a specific file,
sem_routine.c, and the internal usage is simplified to only two
functions (one to insert a new semaphore and one to remove it
from the internal list). There is no need to expose the
internal locking, neither how the semaphore mapping is implemented.
No functional or semantic change is expected, tested on
x86_64-linux-gnu.
