As noted in bug 13888, and as I noted previously in
<https://sourceware.org/ml/libc-alpha/2000-10/msg00111.html>, various
tests used hardcoded paths in /tmp, so posing issues for simultaneous
test runs from different build directories.
This patch fixes such uses of hardcoded file names to put them in the
build directory instead (in the case of stdio-common/bug5 the file
names are changed as well, to avoid a conflict with the name bug5.out
also used for the automatic test output redirection). It also fixes
test-installation.pl likewise (that was using filenames with $$ in
them rather than strictly hardcoded names, but that's still not good
practice for temporary file naming).
Note that my list of files changed is not identical to that in bug
13888. I added tst-spawn3.c and test-installation.pl, and removed
some tests that seem to me (now) to create temporary files securely
(simply using /tmp is not itself a problem if the temporary files are
handled properly with mkstemp; I haven't checked whether those tests
used to do things insecurely). conformtest is not changed because the
makefiles always pass a --tmpdir option so the /tmp default is
irrelevant, and for the same reason there is no actual problem with
nptl/tst-umask1.c because again the makefiles always override the
default.
nptl/sockperf.c is ignored because there is no code to run it;
probably that file should actually be removed.
Some tests use the mktemp function, but I think they all use it in a
way that *is* secure (for generating names for directories / sockets /
fifos / symlinks, where the operation using the name will not follow
symlinks and so there is no potential for a symlink attack on the
account running the testsuite).
Some tests use the tmpnam function to generate temporary file names.
This is in principle insecure, but not addressed by this patch (I
consider it a separate issue from the fully hardcoded paths).
Tested for x86_64.
[BZ #13888]
* posix/Makefile (CFLAGS-tst-spawn3.c): New variable.
* posix/tst-spawn3.c (do_test): Put tst-spwan3.pid in OBJPFX, not
/tmp.
* scripts/test-installation.pl: Put temporary files in build
directory, not /tmp.
* stdio-common/Makefile (CFLAGS-bug3.c): New variable.
(CFLAGS-bug4.c): Likewise.
(CFLAGS-bug5.c): Likewise.
(CFLAGS-test-fseek.c): Likewise.
(CFLAGS-test-popen.c): Likewise.
(CFLAGS-test_rdwr.c): Likewise.
* stdio-common/bug3.c (main): Put temporary file in OBJPFX, not
/tmp.
* stdio-common/bug4.c (main): Likewise.
* stdio-common/bug5.c (main): Likewise.
* stdio-common/test-fseek.c (TESTFILE): Likewise.
* stdio-common/test-popen.c (do_test): Likewise.
* stdio-common/test_rdwr.c (main): Likewise.
true. On some arches this caused valgrind to warn about uninitialized
bytes when the struct was written to the file system.
This patch moves the initialization of pad outside of the
conditional.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
This patch fixes the OFD ("file private") locks for architectures that
support non-LFS flock definition (__USE_FILE_OFFSET64 not defined). The
issue in this case is both F_OFD_{GETLK,SETLK,SETLKW} and
F_{SET,GET}L{W}K64 expects a flock64 argument and when using old
F_OFD_* flags with a non LFS flock argument the kernel might interpret
the underlying data wrongly. Kernel idea originally was to avoid using
such flags in non-LFS syscall, but since GLIBC uses fcntl with LFS
semantic as default it is possible to provide the functionality and
avoid the bogus struct kernel passing by adjusting the struct manually
for the required flags.
The idea follows other LFS interfaces that provide two symbols:
1. A new LFS fcntl64 is added on default ABI with the usual macros to
select it for FILE_OFFSET_BITS=64.
2. The Linux non-LFS fcntl use a stack allocated struct flock64 for
F_OFD_{GETLK,SETLK,SETLKW} copy the results on the user provided
struct.
3. Keep a compat symbol with old broken semantic for architectures
that do not define __OFF_T_MATCHES_OFF64_T.
So for architectures which defines __USE_FILE_OFFSET64, fcntl64 will
aliased to fcntl and no adjustment would be required. So to actually
use F_OFD_* with LFS support the source must be built with LFS support
(_FILE_OFFSET_BITS=64).
Also F_OFD_SETLKW command is handled a cancellation point, as for
F_SETLKW{64}.
Checked on x86_64-linux-gnu and i686-linux-gnu.
[BZ #20251]
* NEWS: Mention fcntl64 addition.
* csu/check_fds.c: Replace __fcntl_nocancel by __fcntl64_nocancel.
* login/utmp_file.c: Likewise.
* sysdeps/posix/fdopendir.c: Likewise.
* sysdeps/posix/opendir.c: Likewise.
* sysdeps/unix/pt-fcntl.c: Likewise.
* include/fcntl.h (__libc_fcntl64, __fcntl64,
__fcntl64_nocancel_adjusted): New prototype.
(__fcntl_nocancel_adjusted): Remove prototype.
* io/Makefile (routines): Add fcntl64.
(CFLAGS-fcntl64.c): New rule.
* io/Versions [GLIBC_2.28] (fcntl64): New symbol.
[GLIBC_PRIVATE] (__libc_fcntl): Rename to __libc_fcntl64.
* io/fcntl.h (fcntl64): Add prototype and redirect if
__USE_FILE_OFFSET64 is defined.
* io/fcntl64.c: New file.
* manual/llio.text: Add a note for which commands fcntl acts a
cancellation point.
* nptl/Makefile (CFLAGS-fcntl64.c): New rule.
* sysdeps/mach/hurd/fcntl.c: Alias fcntl to fcntl64 symbols.
* sysdeps/mach/hurd/i386/libc.abilist [GLIBC_2.28] (fcntl, fcntl64):
New symbols.
* sysdeps/unix/sysv/linux/fcntl.c (__libc_fcntl): Fix F_GETLK64,
F_OFD_GETLK, F_SETLK64, F_SETLKW64, F_OFD_SETLK, and F_OFD_SETLKW for
non-LFS case.
* sysdeps/unix/sysv/linux/fcntl64.c: New file.
* sysdeps/unix/sysv/linux/fcntl_nocancel.c (__fcntl_nocancel): Rename
to __fcntl64_nocancel.
(__fcntl_nocancel_adjusted): Rename to __fcntl64_nocancel_adjusted.
* sysdeps/unix/sysv/linux/not-cancel.h (__fcntl_nocancel): Rename
to __fcntl64_nocancel.
* sysdeps/unix/sysv/linux/tst-ofdlocks.c: New file.
* sysdeps/unix/sysv/linux/tst-ofdlocks-compat.c: Likewise.
* sysdeps/unix/sysv/linux/Makefile (tests): Add tst-ofdlocks.
(tests-internal): Add tst-ofdlocks-compat.
* sysdeps/unix/sysv/linux/aarch64/libc.abilist [GLIBC_2.28]
(fcntl64): New symbol.
* sysdeps/unix/sysv/linux/alpha/libc.abilist: Likewise.
* sysdeps/unix/sysv/linux/ia64/libc.abilist: Likewise.
* sysdeps/unix/sysv/linux/mips/mips64/n64/libc.abilist: Likewise.
* sysdeps/unix/sysv/linux/powerpc/powerpc64/libc.abilist: Likewise.
* sysdeps/unix/sysv/linux/powerpc/powerpc64/libc-le.abilist: Likewise.
* sysdeps/unix/sysv/linux/riscv/rv64/libc.abilist: Likewise.
* sysdeps/unix/sysv/linux/s390/s390-64/libc.abilist: Likewise.
* sysdeps/unix/sysv/linux/sparc/sparc64/libc.abilist: Likewise.
* sysdeps/unix/sysv/linux/x86_64/64/libc.abilist: Likewise.
* sysdeps/unix/sysv/linux/x86_64/x32/libc.abilist: Likewise.
* sysdeps/unix/sysv/linux/arm/libc.abilist [GLIBC_2.28] (fcntl,
fcntl64): Likewise.
* sysdeps/unix/sysv/linux/hppa/libc.abilist: Likewise.
* sysdeps/unix/sysv/linux/i386/libc.abilis: Likewise.
* sysdeps/unix/sysv/linux/m68k/coldfire/libc.abilist: Likewise.
* sysdeps/unix/sysv/linux/m68k/m680x0/libc.abilist: Likewise.
* sysdeps/unix/sysv/linux/microblaze/libc.abilist: Likewise.
* sysdeps/unix/sysv/linux/mips/mips32/fpu/libc.abilist: Likewise.
* sysdeps/unix/sysv/linux/mips/mips32/nofpu/libc.abilist: Likewise.
* sysdeps/unix/sysv/linux/mips/mips64/n32/libc.abilist: Likewise.
* sysdeps/unix/sysv/linux/nios2/libc.abilist: Likewise.
* sysdeps/unix/sysv/linux/powerpc/powerpc32/fpu/libc.abilist:
Likewise.
* sysdeps/unix/sysv/linux/powerpc/powerpc32/nofpu/libc.abilist:
Likewise.
* sysdeps/unix/sysv/linux/s390/s390-32/libc.abilist: Likewise.
* sysdeps/unix/sysv/linux/sh/libc.abilist: Likewise.
* sysdeps/unix/sysv/linux/sparc/sparc32/libc.abilist: Likewise.
If the caller-supplied buffer is not large enough, fall back directly
malloc.
The previous __libc_use_alloca check was incorrect because it did not
take into account that extend_alloca may fail to merge allocations, so
it would underestimate the stack space being used by roughly a factor
of two.
The pre-allocation of the three scratch buffers increased the initial
stack size somewhat, but if retries are needed, the previous version
used more stack space if extend_alloca could not merge allocations.
Lack of alloca accounting also means could be problematic with
extremely large NSS responses, too.
[BZ #18023]
* nscd/aicache.c (addhstaiX): Use struct scratch_buffer instead
of extend_alloca.
Kashubian language is not supported by CLDR, data copied from Wikipedia
and documents released by RJK (official Kashubian Language Council),
also consulted with a native speaker.
Note that this language also needs ab_alt_mon feature due to the month
May: nominative "môj", genitive "maja"; abbreviated nominative "môj",
abbreviated genitive "maj".
[BZ #23140]
* localedata/locales/csb_PL (mon): Rename to...
(alt_mon): This.
(abmon): Rename to...
(ab_alt_mon): This.
(mon): Add with proper genitive forms, copy from Wikipedia.
(abmon): Likewise.
Thank you Michal Ostrowski for the feedback.
[BZ #19485]
* localedata/locales/csb_PL (mon): Fix typos:
"łżëkwiôt" -> "łżëkwiat" (April); "lëpinc" -> "lëpińc" (July).
(yesstr): Add, value is "jo".
(nostr): Add, value is "nié".
Commit 5e79e0292b broke m68k after
s_significand.c became available in the build directory. All m68k
implementations of log1p and significand were including s_significand.c
and stopped working after the inclusion of the the auto-generated file.
This patch reorganizes the implementation of log1p and significand for
m680x0 in order to avoid hitting this problem.
* sysdeps/m68k/m680x0/fpu/s_log1p.c: Set as the generic file for
all log1p and significand functions on m680x0.
* sysdeps/m68k/m680x0/fpu/s_log1pf.c: Include s_log1p.c instead
of s_significand.c..
* sysdeps/m68k/m680x0/fpu/s_log1pl.c: Likewise.
* sysdeps/m68k/m680x0/fpu/s_significandf.c: Likewise.
* sysdeps/m68k/m680x0/fpu/s_significandl.c: Likewise.
* sysdeps/m68k/m680x0/fpu/s_significand.c: Move all the code to
s_log1p.c and include it..
Signed-off-by: Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com>
The BPF ELF format has new relocation types R_BPF_64_64 and R_BPF_64_32.
The existing R_BPF_MAP_FD was an extension that never got implemented.
Remove it, because the constant conflicts with the official R_BPF_64_64.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Building the testsuite with GCC mainline fails with
-Wstringop-overflow= errors in string/tst-cmp.c. These are for calls
to strncmp and strncasecmp with SIZE_MAX size argument. The tests are
deliberately using this size that would be dubious in normal code, so
this patch disables the warning for the calls in question.
Tested with build-many-glibcs.py for aarch64-linux-gnu.
* string/tst-cmp.c: Include <libc-diag.h>.
(strncmp_max): Disable -Wstringop-overflow= around call to
strncmp.
(strncasecmp_max): Disable -Wstringop-overflow= around call to
strncasecmp.
Building the testsuite with GCC mainline fails with:
bug-strspn1.c: In function 'main':
bug-strspn1.c:14:3: error: right-hand operand of comma expression has no effect [-Werror=unused-value]
strspn (b++, "");
^~~~~~~~~~~~~~~~
and a similar error for bug-strpbrk1.c. I'm not sure what GCC change
introduced this, and the wording of the message is a bit off (in the
source it's not a comma expression, that must reflect GCC's IR). But
the warning is correct (strspn is a pure function, the call is
useless, and if there wasn't an argument with a side effect much older
GCC would have warned); the point of the test is to verify that the
side effect in an argument still occurs for this useless call that can
otherwise be optimized to an (unused) constant (testing for a bug
there once was in an old strspn macro). This patch duly arranges for
the warning to be disabled for this code.
Tested with build-many-glibcs.py for aarch64-linux-gnu.
* string/bug-strpbrk1.c: Include <libc-diag.h>.
(main): Disable -Wunused-value around call to strpbrk.
* string/bug-strspn1.c: Include <libc-diag.h>.
(main): Disable -Wunused-value around call to strspn.
Add a new libm-alias-float128.h in order to provide the __*ieee128
aliases for the existing *f128 that do not have a globally exported
symbol.
* sysdeps/ieee754/ldbl-128ibm-compat/Versions: New file.
* sysdeps/ieee754/ldbl-128ibm-compat/libm-alias-float128.h: New file.
Move declare_mgen_finite_alias, declare_mgen_finite_alias_s and
declare_mgen_finite_alias_x to a shared place in order to reuse them in
other files that also declare _finite aliases.
* math/e_exp2_template.c (declare_mgen_finite_alias,
declare_mgen_finite_alias_s, declare_mgen_finite_alias_x): Move to...
* sysdeps/generic/math-type-macros.h (declare_mgen_finite_alias,
declare_mgen_finite_alias_s, declare_mgen_finite_alias_x): ... here.
Signed-off-by: Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com>
As reported in bug 23280, scanf functions produce incorrectly rounded
result for floating-point formats in FE_UPWARD and FE_DOWNWARD modes,
because they pass the input with sign removed to strtod functions, and
then negate the result if there was a '-' at the start of the input.
This patch fixes this by arranging for the sign to be passed to strtod
rather than scanf doing the negation itself. In turn, keeping the
sign around in the buffer being built up for strtod requires updating
places that examine char_buffer_size (&charbuf) to allow for the sign
being there as an extra character.
Tested for x86_64.
[BZ #23280]
* stdio-common/vfscanf.c (_IO_vfscanf_internal): Pass sign of
floating-point number to strtod functions rather than possibly
negating result of those functions.
* stdio-common/tst-scanf-round.c: New file.
* stdio-common/Makefile (tests): Add tst-scanf-round.
($(objpfx)tst-scanf-round): Depend on $(libm).
This patch updates the hppa definition of MAP_TYPE to reflect a
corresponding change in the Linux kernel in 4.17 (so the value now has
four bits set, as it does on other architectures, although they are
different from other architectures because of hppa differences in
other MAP_* bits).
Tested with build-many-glibcs.py for hppa.
* sysdeps/unix/sysv/linux/hppa/bits/mman.h [__USE_MISC]
(MAP_TYPE): Change value to 0x2b.
My recent nan-sign tests fail to build for powerpc64le with GCC 8
because of the special compile / link options needed there for any
test using _Float128. This patch arranges for these tests to be
handled on powerpc64le similarly to other such tests.
Tested with build-many-glibcs.py for powerpc64le.
[BZ #23303]
* sysdeps/powerpc/powerpc64/le/Makefile
(CFLAGS-tst-strtod-nan-sign.c): Add -mfloat128.
(CFLAGS-tst-wcstod-nan-sign.c): Likewise.
(gnulib-tests): Also add $(f128-loader-link) for
tst-strtod-nan-sign abd tst-wcstod-nan-sign.
* sysdeps/mach/include/mach-shortcuts-hidden.h: New file.
* mach/shortcut.awk: Make syscall stubs include
<mach-shortcuts-hidden.h> and add hidden definition.
* sysdeps/mach/include/mach.h: Include <mach-shortcuts-hidden.h>.
* sysdeps/mach/hurd/lseek.c: Include <errno.h>.
* sysdeps/mach/hurd/lseek.c (__libc_lseek): Check that the value returned
by __lseek64 can fit off_t, return EOVERFLOW otherwise.
This patch adds tests for bug 23007, strtod ignoring any sign in the
input string in the case of a NaN result.
Tested for x86_64.
[BZ #23007]
* stdlib/tst-strtod-nan-sign-main.c: New file.
* stdlib/tst-strtod-nan-sign.c: Likewise.
* wcsmbs/tst-wcstod-nan-sign.c: Likewise.
* stdlib/Makefile (tests): Add tst-strtod-nan-sign.
($(objpfx)tst-strtod-nan-sign): Depend on $(libm).
* wcsmbs/Makefile (tests) Add tst-wcstod-nan-sign.
($(objpfx)tst-wcstod-nan-sign): Depend on $(libm).
As reported in bug 23007, strtod ignores any sign in the input string
in the case of a NaN result. Thes patch fixes this.
Tested for x86_64 (in conjunction with tests to be added separately).
[BZ #23007]
* stdlib/strtod_l.c (____STRTOF_INTERNAL): Return NaN of
appropriate sign.
