This code path is exercised indirectly by some of the DNS stub
resolver tests, via their own use of xopen_memstream for constructing
strings describing result data. The relative lack of test suite
coverage became apparent when these tests starting failing after a
printf changes uncovered bug 28949.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
The siglist.c is built with -fno-toplevel-reorder to avoid compiler
to reorder the compat assembly directives due an assembler
issue [1] (fixed on 2.39).
This patch removes the compiler flags by split the compat symbol
generation in two phases. First the __sys_siglist and __sys_sigabbrev
without any compat symbol directive is preprocessed to generate an
assembly source code. This generate assembly is then used as input
on a platform agnostic siglist.S which then creates the compat
definitions. This prevents compiler to move any compat directive
prior the _sys_errlist definition itself.
Checked on a make check run-built-tests=no on all affected ABIs.
Reviewed-by: Fangrui Song <maskray@google.com>
The errlist.c is built with -fno-toplevel-reorder to avoid compiler to
reorder the compat assembly directives due an assembler issue [1]
(fixed on 2.39).
This patch removes the compiler flags by split the compat symbol
generation in two phases. First the _sys_errlist_internal internal
without any compat symbol directive is preprocessed to generate an
assembly source code. This generate assembly is then used as input
on a platform agnostic errlist-data.S which then creates the compat
definitions. This prevents compiler to move any compat directive
prior the _sys_errlist_internal definition itself.
Checked on a make check run-built-tests=no on all affected ABIs.
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=29012
The loader does not need to pull all __get_errlist definitions
and its size is decreased:
Before:
$ size elf/ld.so
text data bss dec hex filename
197774 11024 456 209254 33166 elf/ld.so
After:
$ size elf/ld.so
text data bss dec hex filename
191510 9936 456 201902 314ae elf/ld.so
Checked on x86_64-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
%#m prints errno as an error constant if one is available, or
a decimal number as a fallback. This intends to address the gap
that strerrorname_np does not work well with printf for unknown
error codes due to its NULL return values in those cases.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
C2X adds a printf %b format (see
<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2630.pdf>, accepted
for C2X), for outputting integers in binary. It also has recommended
practice for a corresponding %B format (like %b, but %#B starts the
output with 0B instead of 0b). Add support for these formats to
glibc.
One existing test uses %b as an example of an unknown format, to test
how glibc printf handles unknown formats; change that to %v. Use of
%b and %B as user-registered format specifiers continues to work (and
we already have a test that covers that, tst-printfsz.c).
Note that C2X also has scanf %b support, plus support for binary
constants starting 0b in strtol (base 0 and 2) and scanf %i (strtol
base 0 and scanf %i coming from a previous paper that added binary
integer literals). I intend to implement those features in a separate
patch or patches; as discussed in the thread starting at
<https://sourceware.org/pipermail/libc-alpha/2020-December/120414.html>,
they will be more complicated because they involve adding extra public
symbols to ensure compatibility with existing code that might not
expect 0b constants to be handled by strtol base 0 and 2 and scanf %i,
whereas simply adding a new format specifier poses no such
compatibility concerns.
Note that the actual conversion from integer to string uses existing
code in _itoa.c. That code has special cases for bases 8, 10 and 16,
probably so that the compiler can optimize division by an integer
constant in the code for those bases. If desired such special cases
could easily be added for base 2 as well, but that would be an
optimization, not actually needed for these printf formats to work.
Tested for x86_64 and x86. Also tested with build-many-glibcs.py for
aarch64-linux-gnu with GCC mainline to make sure that the test does
indeed build with GCC 12 (where format checking warnings are enabled
for most of the test).
Remove all malloc hook uses from core malloc functions and move it
into a new library libc_malloc_debug.so. With this, the hooks now no
longer have any effect on the core library.
libc_malloc_debug.so is a malloc interposer that needs to be preloaded
to get hooks functionality back so that the debugging features that
depend on the hooks, i.e. malloc-check, mcheck and mtrace work again.
Without the preloaded DSO these debugging features will be nops.
These features will be ported away from hooks in subsequent patches.
Similarly, legacy applications that need hooks functionality need to
preload libc_malloc_debug.so.
The symbols exported by libc_malloc_debug.so are maintained at exactly
the same version as libc.so.
Finally, static binaries will no longer be able to use malloc
debugging features since they cannot preload the debugging DSO.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Tested-by: Carlos O'Donell <carlos@redhat.com>
The symbol has never been exported, so no compatibility symbol is
needed. Removing this file prevents ld from creation an exported
symbol in case GLIBC_2_0 expands to a symbol version which
does not have a local: *; directive in the symbol version map file.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
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
It returns the string of the error constant, not its description (as
strerrordesc_np). To handle the Hurd error mapping, the ERR_MAP was
removed from errlist.h to errlist.c.
Also, the testcase test-strerr (added on 325081b9eb) was not added
on the check build neither it builds correctly. This patch also
changed it to decouple from errlist.h, the expected return values
are added explicitly for both both strerrorname_np and strerrordesc_np
directly.
Checked on x86_64-linux-gnu and i686-linux-gnu. I also run a make
check for i686-gnu.
__printf_fp_l has a memory leak in the case of some I/O errors, where
both buffer and wbuffer have been malloced but the handling of I/O
errors only frees wbuffer. This patch fixes this by moving the
declaration of buffer to an outer scope and ensuring that it is freed
when wbuffer is freed.
Tested for x86_64 and x86.
__printf_fp_l has a double free bug in the case where it allocates
memory with malloc internally, then has an I/O error while outputting
trailing padding and tries to free that already-freed memory when the
error occurs. This patch fixes this by setting the relevant pointer
to NULL after the first free (the only free of this pointer that isn't
immediately followed by returning from the function).
Tested for x86_64 and x86.
The symbol is deprecated by strerror since its usage imposes some issues
such as copy relocations.
Its internal name is also changed to _sys_errlist_internal to avoid
static linking usage. The compat code is also refactored by removing
the over enginered errlist-compat.c generation from manual entried and
extra comment token in linker script file. It disantangle the code
generation from manual and simplify both Linux and Hurd compat code.
The definitions from errlist.c are moved to errlist.h and a new test
is added to avoid a new errno entry without an associated one in manual.
Checked on x86_64-linux-gnu and i686-linux-gnu. I also run a check-abi
on all affected platforms.
Tested-by: Carlos O'Donell <carlos@redhat.com>
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
The vfprintf implementation (used for all printf-family functions)
contains complicated logic to allocate internal buffers of a size
depending on the width and precision used for a format, using either
malloc or alloca depending on that size, and with consequent checks
for size overflow and allocation failure.
As noted in bug 26211, the version of that logic used when '$' plus
argument number formats are in use is missing the overflow checks,
which can result in segfaults (quite possibly exploitable, I didn't
try to work that out) when the width or precision is in the range
0x7fffffe0 through 0x7fffffff (maybe smaller values as well in the
wprintf case on 32-bit systems, when the multiplication by sizeof
(CHAR_T) can overflow).
All that complicated logic in fact appears to be useless. As far as I
can tell, there has been no need (outside the floating-point printf
code, which does its own allocations) for allocations depending on
width or precision since commit
3e95f6602b ("Remove limitation on size
of precision for integers", Sun Sep 12 21:23:32 1999 +0000). Thus,
this patch removes that logic completely, thereby fixing both problems
with excessive allocations for large width and precision for
non-floating-point formats, and the problem with missing overflow
checks with such allocations. Note that this does have the
consequence that width and precision up to INT_MAX are now allowed
where previously INT_MAX / sizeof (CHAR_T) - EXTSIZ or more would have
been rejected, so could potentially expose any other overflows where
the value would previously have been rejected by those removed checks.
I believe this completely fixes bugs 14231 and 26211.
Excessive allocations are still possible in the floating-point case
(bug 21127), as are other integer or buffer overflows (see bug 26201).
This does not address the cases where a precision larger than INT_MAX
(embedded in the format string) would be meaningful without printf's
return value overflowing (when it's used with a string format, or %g
without the '#' flag, so the actual output will be much smaller), as
mentioned in bug 17829 comment 8; using size_t internally for
precision to handle that case would be complicated by struct
printf_info being a public ABI. Nor does it address the matter of an
INT_MIN width being negated (bug 17829 comment 7; the same logic
appears a second time in the file as well, in the form of multiplying
by -1). There may be other sources of memory allocations with malloc
in printf functions as well (bug 24988, bug 16060). From inspection,
I think there are also integer overflows in two copies of "if ((width
-= len) < 0)" logic (where width is int, len is size_t and a very long
string could result in spurious padding being output on a 32-bit
system before printf overflows the count of output characters).
Tested for x86-64 and x86.
The only difference between noncompliant and C99-compliant scanf is
that the former accepts the archaic GNU extension '%as' (also %aS and
%a[...]) meaning to allocate space for the input string with malloc.
This extension conflicts with C99's use of %a as a format _type_
meaning to read a floating-point number; POSIX.1-2008 standardized
equivalent functionality using the modifier letter 'm' instead (%ms,
%mS, %m[...]).
The extension was already disabled in most conformance modes:
specifically, any mode that doesn't involve _GNU_SOURCE and _does_
involve either strict conformance to C99 or loose conformance to both
C99 and POSIX.1-2001 would get the C99-compliant scanf. With
compilers new enough to use -std=gnu11 instead of -std=gnu89, or
equivalent, that includes the default mode.
With this patch, we now provide C99-compliant scanf in all
configurations except when _GNU_SOURCE is defined *and*
__STDC_VERSION__ or __cplusplus (whichever is relevant) indicates
C89/C++98. This leaves the old scanf available under e.g. -std=c89
-D_GNU_SOURCE, but removes it from e.g. -std=gnu11 -D_GNU_SOURCE (it
was already not present under -std=gnu11 without -D_GNU_SOURCE) and
from -std=gnu89 without -D_GNU_SOURCE.
There needs to be an internal override so we can compile the
noncompliant scanf itself. This is the same problem we had when we
removed 'gets' from _GNU_SOURCE and it's dealt with the same way:
there's a new __GLIBC_USE symbol, DEPRECATED_SCANF, which defaults to
off under the appropriate conditions for external code, but can be
overridden by individual files within stdio.
We also run into problems with PLT bypass for internal uses of sscanf,
because libc_hidden_proto uses __REDIRECT and so does the logic in
stdio.h for choosing which implementation of scanf to use; __REDIRECT
isn't transitive, so include/stdio.h needs to bridge the gap with a
macro. As far as I can tell, sscanf is the only function in this
family that's internally called by unrelated code.
Finally, there are several tests in stdio-common that use the
extension. bug21.c is a regression test for a crash; it still
exercises the relevant code when changed to use %ms instead of %as.
scanf14.c through scanf17.c are more complicated since they are
actually testing the subtleties of the extension - under what
circumstances is 'a' treated as a modifier letter, etc. I changed all
of them to use %ms instead of %as as well, but duplicated scanf14.c
and scanf16.c as scanf14a.c and scanf16a.c. These still use %as and
are compiled with -std=gnu89 to access the old extension. A bunch of
diagnostic overrides and manual workarounds for the old stdio.h
behavior become unnecessary. Yay!
* include/features.h (__GLIBC_USE_DEPRECATED_SCANF): New __GLIBC_USE
parameter. Only use deprecated scanf when __USE_GNU is defined
and __STDC_VERSION__ is less than 199901L or __cplusplus is less
than 201103L, whichever is relevant for the language being compiled.
* libio/stdio.h, libio/bits/stdio-ldbl.h: Decide whether to redirect
scanf, fscanf, sscanf, vscanf, vfscanf, and vsscanf to their
__isoc99_ variants based only on __GLIBC_USE (DEPRECATED_SCANF).
* wcsmbs/wchar.h: wcsmbs/bits/wchar-ldbl.h: Likewise for
wscanf, fwscanf, swscanf, vwscanf, vfwscanf, and vswscanf.
* libio/iovsscanf.c
* libio/fwscanf.c
* libio/iovswscanf.c
* libio/swscanf.c
* libio/vscanf.c
* libio/vwscanf.c
* libio/wscanf.c
* stdio-common/fscanf.c
* stdio-common/scanf.c
* stdio-common/vfscanf.c
* stdio-common/vfwscanf.c
* sysdeps/ieee754/ldbl-opt/nldbl-compat.c
* sysdeps/ieee754/ldbl-opt/nldbl-fscanf.c
* sysdeps/ieee754/ldbl-opt/nldbl-fwscanf.c
* sysdeps/ieee754/ldbl-opt/nldbl-iovfscanf.c
* sysdeps/ieee754/ldbl-opt/nldbl-scanf.c
* sysdeps/ieee754/ldbl-opt/nldbl-sscanf.c
* sysdeps/ieee754/ldbl-opt/nldbl-swscanf.c
* sysdeps/ieee754/ldbl-opt/nldbl-vfscanf.c
* sysdeps/ieee754/ldbl-opt/nldbl-vfwscanf.c
* sysdeps/ieee754/ldbl-opt/nldbl-vscanf.c
* sysdeps/ieee754/ldbl-opt/nldbl-vsscanf.c
* sysdeps/ieee754/ldbl-opt/nldbl-vswscanf.c
* sysdeps/ieee754/ldbl-opt/nldbl-vwscanf.c
* sysdeps/ieee754/ldbl-opt/nldbl-wscanf.c:
Override __GLIBC_USE_DEPRECATED_SCANF to 1.
* stdio-common/sscanf.c: Likewise. Remove ldbl_hidden_def for __sscanf.
* stdio-common/isoc99_sscanf.c: Add libc_hidden_def for __isoc99_sscanf.
* include/stdio.h: Provide libc_hidden_proto for __isoc99_sscanf,
not sscanf.
[!__GLIBC_USE (DEPRECATED_SCANF)]: Define sscanf as __isoc99_scanf
with a preprocessor macro.
* stdio-common/bug21.c, stdio-common/scanf14.c:
Use %ms instead of %as, %mS instead of %aS, %m[] instead of %a[];
remove DIAG_IGNORE_NEEDS_COMMENT for -Wformat.
* stdio-common/scanf16.c: Likewise. Add __attribute__ ((format (scanf)))
to xscanf, xfscanf, xsscanf.
* stdio-common/scanf14a.c: New copy of scanf14.c which still uses
%as, %aS, %a[]. Remove DIAG_IGNORE_NEEDS_COMMENT for -Wformat.
* stdio-common/scanf16a.c: New copy of scanf16.c which still uses
%as, %aS, %a[]. Add __attribute__ ((format (scanf))) to xscanf,
xfscanf, xsscanf.
* stdio-common/scanf15.c, stdio-common/scanf17.c: No need to
override feature selection macros or provide definitions of u_char etc.
* stdio-common/Makefile (tests): Add scanf14a and scanf16a.
(CFLAGS-scanf15.c, CFLAGS-scanf17.c): Remove.
(CFLAGS-scanf14a.c, CFLAGS-scanf16a.c): New. Compile these files
with -std=gnu89.
The _chk variants of all of the printf functions become much simpler.
This is the last thing that we needed _IO_acquire_lock_clear_flags2
for, so it can go as well. I took the opportunity to make the headers
included and the names of all local variables consistent across all the
affected files.
Since we ultimately want to get rid of __no_long_double as well, it
must be possible to get all of the nontrivial effects of the _chk
functions by calling the _internal functions with appropriate flags.
For most of the __(v)xprintf_chk functions, this is covered by
PRINTF_FORTIFY plus some up-front argument checks that can be
duplicated. However, __(v)sprintf_chk installs a custom jump table so
that it can crash instead of overflowing the output buffer. This
functionality is moved to __vsprintf_internal, which now has a
'maxlen' argument like __vsnprintf_internal; to get the unsafe
behavior of ordinary (v)sprintf, pass -1 for that argument.
obstack_printf_chk and obstack_vprintf_chk are no longer in the same
file.
As a side-effect of the unification of both fortified and non-fortified
vdprintf initialization, this patch fixes bug 11319 for __dprintf_chk
and __vdprintf_chk, which was previously fixed only for dprintf and
vdprintf by the commit
commit 7ca890b88e
Author: Ulrich Drepper <drepper@redhat.com>
Date: Wed Feb 24 16:07:57 2010 -0800
Fix reporting of I/O errors in *dprintf functions.
This patch adds a test case to avoid regressions.
Tested for powerpc and powerpc64le.
There are a lot more printf variants than there are scanf variants,
and the code for setting up and tearing down their custom FILE
variants around the call to __vf(w)printf is more complicated and
variable. Therefore, I have added _internal versions of all the
v*printf variants, rather than introducing helper routines so that
they can all directly call __vf(w)printf_internal, as was done with
scanf.
As with the scanf changes, in this patch the _internal functions still
look at the environmental mode bits and all callers pass 0 for the
flags parameter.
Several of the affected public functions had _IO_ name aliases that
were not exported (but, in one case, appeared in libio.h anyway);
I was originally planning to leave them as aliases to avoid having
to touch internal callers, but it turns out ldbl_*_alias only work
for exported symbols, so they've all been removed instead. It also
turns out there were hardly any internal callers. _IO_vsprintf and
_IO_vfprintf *are* exported, so those two stick around.
Summary for the changes to each of the affected symbols:
_IO_vfprintf, _IO_vsprintf:
All internal calls removed, thus the internal declarations, as well
as uses of libc_hidden_proto and libc_hidden_def, were also removed.
The external symbol is now exposed via uses of ldbl_strong_alias
to __vfprintf_internal and __vsprintf_internal, respectively.
_IO_vasprintf, _IO_vdprintf, _IO_vsnprintf,
_IO_vfwprintf, _IO_vswprintf,
_IO_obstack_vprintf, _IO_obstack_printf:
All internal calls removed, thus declaration in internal headers
were also removed. They were never exported, so there are no
aliases tying them to the internal functions. I.e.: entirely gone.
__vsnprintf:
Internal calls were always preceded by macros such as
#define __vsnprintf _IO_vsnprintf, and
#define __vsnprintf vsnprintf
The macros were removed and their uses replaced with calls to the
new internal function __vsnprintf_internal. Since there were no
internal calls, the internal declaration was also removed. The
external symbol is preserved with ldbl_weak_alias to ___vsnprintf.
__vfwprintf:
All internal calls converted into calls to __vfwprintf_internal,
thus the internal declaration was removed. The function is now a
wrapper that calls __vfwprintf_internal. The external symbol is
preserved.
__vswprintf:
Similarly, but no external symbol.
__vasprintf, __vdprintf, __vfprintf, __vsprintf:
New internal wrappers. Not exported.
vasprintf, vdprintf, vfprintf, vsprintf, vsnprintf,
vfwprintf, vswprintf,
obstack_vprintf, obstack_printf:
These functions used to be aliases to the respective _IO_* function,
they are now aliases to their respective __* functions.
Tested for powerpc and powerpc64le.
There are two flags currently defined: SCANF_LDBL_IS_DBL is the mode
used by __nldbl_ scanf variants, and SCANF_ISOC99_A is the mode used
by __isoc99_ scanf variants. In this patch, the new functions honor
these flag bits if they're set, but they still also look at the
corresponding bits of environmental state, and callers all pass zero.
The new functions do *not* have the "errp" argument possessed by
_IO_vfscanf and _IO_vfwscanf. All internal callers passed NULL for
that argument. External callers could theoretically exist, so I
preserved wrappers, but they are flagged as compat symbols and they
don't preserve the three-way distinction among types of errors that
was formerly exposed. These functions probably should have been in
the list of deprecated _IO_ symbols in 2.27 NEWS -- they're not just
aliases for vfscanf and vfwscanf.
(It was necessary to introduce ldbl_compat_symbol for _IO_vfscanf.
Please check that part of the patch very carefully, I am still not
confident I understand all of the details of ldbl-opt.)
This patch also introduces helper inlines in libio/strfile.h that
encapsulate the process of initializing an _IO_strfile object for
reading. This allows us to call __vfscanf_internal directly from
sscanf, and __vfwscanf_internal directly from swscanf, without
duplicating the initialization code. (Previously, they called their
v-counterparts, but that won't work if we want to control *both* C99
mode and ldbl-is-dbl mode using the flags argument to__vfscanf_internal.)
It's still a little awkward, especially for wide strfiles, but it's
much better than what we had.
Tested for powerpc and powerpc64le.
The implementation falls back to renameat if renameat2 is not available
in the kernel (or in the kernel headers) and the flags argument is zero.
Without kernel support, a non-zero argument returns EINVAL, not ENOSYS.
This mirrors what the kernel does for invalid renameat2 flags.
Since the addition of the _Float128 API, strfromf128 and printf_size use
__printf_fp to print _Float128 values. This is achieved by setting the
'is_binary128' member of the 'printf_info' structure to one. Now that
the format of long double on powerpc64le is getting a third option, this
mechanism is reused for long double values that have binary128 format
(i.e.: when -mabi=ieeelongdouble).
This patch adds __printf_sizeieee128 as an exported symbol, but doesn't
provide redirections from printf_size, yet. All redirections will be
installed in a future commit, once all other functions that print or
read long double values with binary128 format are ready. In
__printf_fp, when 'is_binary128' is one, the floating-point argument is
treated as if it was of _Float128 type, regardless of the value of
'is_long_double', thus __printf_sizeieee128 sets 'is_binary128' to the
same value of 'is_long_double'. Otherwise, double values would not be
printed correctly.
Tested for powerpc64le.
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.
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 adds O_TMPFILE support to tmpfile on Linux. This is
similar to the previous suggestion by Andreas Schwab [1] with the
difference the file descriptor creation is parameterized to
compartmentalize Linux only open flags (O_TMPFILE) on sysdeps.
Checked on x86_64-linux-gnu.
Adhemerval Zanella <adhemerval.zanella@linaro.org>
Andreas Schwab <schwab@suse.de>
[BZ #21530]
* include/stdio.h (__gen_tempfd): New function.
* stdio-common/Makefile (routines): Add gentempfd.
* stdio-common/gentempfd.c: New file.
* sysdeps/unix/sysv/linux/gentempfd.c: Likewise.
* stdio-common/tmpfile.c (tmpfile): First try to use a system specific
unnamed file first.
[1] https://sourceware.org/ml/libc-alpha/2017-06/msg01293.html
gets has the dubious honor of being the only C89 library feature that
has been completely removed from the current C and C++ standards.
glibc follows suit by not declaring it in _GNU_SOURCE mode either,
but it remains present in older compatibility modes. Internally,
two test cases need to see stdio.h make the declaration, but all our
internal code is of course compiled under _GNU_SOURCE. This is currently
kludged by duplicating the gets declaration, fortify wrapper and all,
in include/stdio.h. Also, the conditional in the public headers for
deciding when to declare gets is complicated and repeated in two places.
This patch adds a new macro to features.h that encapsulates the
complicated rule for when to declare gets. stdio.h and bits/stdio2.h
then simply test __GLIBC_USE (DEPRECATED_GETS), and instead of having
a duplicate gets declaration in include/stdio.h, debug/tst-chk1.c and
stdio-common/tst-gets.c can force gets to be declared.
* include/features.h (__GLIBC_USE_DEPRECATED_GETS): New macro.
* libio/stdio.h, libio/bits/stdio2.h: Condition gets on
__GLIBC_USE (DEPRECATED_GETS). Update comments to indicate
gets was removed from C++ in C++14.
* include/stdio.h: Remove redundant declaration of gets.
* debug/tst-chk1.c, stdio-common/tst-gets.c: Force gets to
be declared, since we are testing it.
* stdio-common/Makefile (tst-gets.c): Compile with
-Wno-deprecated-declarations.
* debug/Makefile (tst-chk1.c, tst-chk2.c, tst-chk3.c, tst-chk4.cc)
(tst-chk5.cc, tst-chk6.cc, tst-lfschk1.c, tst-lfschk2.c)
(tst-lfschk3.c, tst-lfschk4.cc, tst-lfschk5.cc, tst-lfschk6.cc):
Compile with -Wno-deprecated-declarations.
Current GLIBC fmemopen fails with a simple testcase:
char buffer[500] = "x";
FILE *stream;
stream = fmemopen(buffer, 500, "r+");
fwrite("fish",sizeof(char),5,stream);
printf("pos-1:%ld\n",ftell(stream));
fflush(stream);
printf("pos-2:%ld\n",ftell(stream));
It returns:
pos-1:5
pos-2:0
Where it should return:
pos-1:5
pos-2:5
This is due the internal write function does not correctly update the internal
object position state and then the seek operation returns a wrong value. This
patch fixes it.
It fixes both BZ #20005 and BZ #19230 (marked as duplicated). A new test is
added to check for such case.
Tested on x86_64 and i686.
* libio/fmemopen.c (fmemopen_write): Update internal position after
write.
* stdio-common/Makefile (tests): Add tst-fmemopen4.c.
* stdio-common/tst-fmemopen4.c: New file..
This patch added a new fmemopen version, for glibc 2.22, that aims to be
POSIX complaint. It fixes some long-stading glibc fmemopen issues, such
as:
* it changes the way fseek with SEEK_END works on fmemopen to seek
relative to buffer size instead of first '\0'. This is default mode and
'b' opening mode does not change internal behavior (bz#6544).
* fix apending opening mode to use as start position either first null
byte of len specified in function call (bz#13152 and #13151).
* remove binary option 'b' and internal different handling (bz#12836)
* fix seek/SEE_END with negative values (bz#14292).
A compatibility symbol is provided to with old behavior for older symbols
version (2.2.5).
* include/stdio.h (fmemopen): Remove hidden prototype.
(__fmemopen): Add new hidden prototype.
* libio/Makefile: Add oldfmemopen object.
* libio/Versions [GLIBC_2.22]: Add new fmemopen symbol.
* libio/fmemopen.c (__fmemopen): Function rewrite to be POSIX
compliance.
* libio/oldfmemopen.c: New file: old fmemopen implementation for
symbol compatibility.
* stdio-common/Makefile [tests]: Add new tst-fmemopen3.
* stdio-common/psiginfo.c [psiginfo]: Call __fmemopen instead of
fmemopen.
* stdio-common/tst-fmemopen3.c: New file: more fmemopen tests, focus
on append and read mode.
* sysdeps/unix/sysv/linux/aarch64/libc.abilist [GLIBC_2.22]: Add
fmemopen.
* sysdeps/unix/sysv/linux/alpha/libc.abilist [GLIBC_2.22]: Likewise.
* sysdeps/unix/sysv/linux/arm/libc.abilist [GLIBC_2.22]: Likewise.
* sysdeps/unix/sysv/linux/i386/libc.abilist [GLIBC_2.22]: Likewise.
* sysdeps/unix/sysv/linux/ia64/libc.abilist [GLIBC_2.22]:
Likewise.
* sysdeps/unix/sysv/linux/m68k/coldfire/libc.abilist
[GLIBC_2.22]: Likewise.
* sysdeps/unix/sysv/linux/m68k/m680x0/libc.abilist [GLIBC_2.22]:
Likewise.
* sysdeps/unix/sysv/linux/microblaze/libc.abilist [GLIBC_2.22]:
Likewise.
* sysdeps/unix/sysv/linux/mips/mips32/fpu/libc.abilist
[GLIBC_2.22]: Likewise.
* sysdeps/unix/sysv/linux/mips/mips32/nofpu/libc.abilist
[GLIBC_2.22]: Likewise.
* sysdeps/unix/sysv/linux/mips/mips64/n32/libc.abilist
[GLIBC_2.22]: Likewise.
* sysdeps/unix/sysv/linux/mips/mips64/n64/libc.abilist
[GLIBC_2.22]: Likewise.
* sysdeps/unix/sysv/linux/powerpc/powerpc32/fpu/libc.abilist
[GLIBC_2.22]: Likewise.
* sysdeps/unix/sysv/linux/powerpc/powerpc32/nofpu/libc.abilist
[GLIBC_2.22]: Likewise.
* sysdeps/unix/sysv/linux/powerpc/powerpc64/libc.abilist
[GLIBC_2.22]: Likewise.
* sysdeps/unix/sysv/linux/s390/s390-32/libc.abilist [GLIBC_2.22]:
Likewise.
* sysdeps/unix/sysv/linux/s390/s390-64/libc.abilist [GLIBC_2.22]:
Likewise.
* sysdeps/unix/sysv/linux/sh/libc.abilist [GLIBC_2.22]: Likewise.
* sysdeps/unix/sysv/linux/sparc/sparc32/libc.abilist
[GLIBC_2.22]: Likewise.
* sysdeps/unix/sysv/linux/sparc/sparc64/libc.abilist
[GLIBC_2.22]: Likewise.
* sysdeps/unix/sysv/linux/tile/tilegx/tilegx32/libc.abilist
[GLIBC_2.22]: Likewise.
* sysdeps/unix/sysv/linux/tile/tilegx/tilegx64/libc.abilist
[GLIBC_2.22]: Likewise.
* sysdeps/unix/sysv/linux/tile/tilepro/libc.abilist [GLIBC_2.22]:
Likewise.
* sysdeps/unix/sysv/linux/x86_64/64/libc.abilist [GLIBC_2.22]:
Likewise.
* sysdeps/unix/sysv/linux/x86_64/x32/libc.abilist [GLIBC_2.22]:
Likewise.
* sysdeps/unix/sysv/linux/hppa/libc.abilist [GLIBC_2.22]: Likewise.
* sysdeps/unix/sysv/linux/nios2/libc.abilist [GLIBC_2.22]: Likewise.
