| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Linux uses different expressions for the RENAME_* and AT_RENAME_*
constants. Mirror that in <stdio.h>, so that the macro redefinitions
do not result in preprocessor warnings.
Reviewed-by: Collin Funk <collin.funk1@gmail.com>
|
|
Convert (some) tests to use 'xfclose' rather than using plain 'fclose'
call with no error checking or plain missing such a call.
Reviewed-by: Florian Weimer <fweimer@redhat.com>
|
|
Convert tests to use 'xfmemopen' rather than open-coding error checks
with 'fmemopen' or plain missing them, where 'fmemopen' itself is not
the scope of testing. Leave 'fmemopen' tests alone.
Reviewed-by: Florian Weimer <fweimer@redhat.com>
|
|
Mode 0777 should be used for directories only because it results
in executable entries (after typical umasks are applied).
Reviewed-by: Arjun Shankar <arjun@redhat.com>
|
|
Convert 'compare_real', 'read_real', and 'verify_input' macros to
functions so as to improve readability and avoid pitfalls.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
|
|
Move the inclusion of the data class header from the individual tests to
the data-type-specific skeleton, providing for the use of the data type
under test in the data class header and reducing duplication.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
|
|
Follow 'scanf' itself and use the system header inclusion variant for
the data-type-specific skeleton consistently across the remaining scanf
family functions so that any sysdeps/ variant takes precedence even in
the presence of a corresponding skeleton in stdio-common/ (though we
have no such arrangement at the moment).
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
|
|
Fix a null pointer dereference causing a crash in 'read_real' when the
terminating null character is written for use with the subsequent call
to 'nan' for invalid NaN reference input, such as:
%a:nan:1:3:nanny:
by moving all the 'n-char-sequence' handling under the check for the
opening parenthesis.
No test case added as it's a test case issue in the first place.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
|
|
Fix a null pointer dereference causing a crash in 'read_real' when the
terminating null character is written for use with the subsequent call
to 'nan' for NaN reference input using null 'n-char-sequence', such as:
%a:nan():1:5:nan():
by moving the memory allocation call ahead of the check for the closing
parenthesis.
No test case added as it's a test case issue in the first place.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
|
|
Remove buffer contents reporting from the real variant of 'verify_input'
where there has been an input data format error making the contents of
data buffers irrelevant.
For example given invalid float input data:
%a:nan:1:3:nan(:
these messages are produced:
error: ./tst-scanf-format-skeleton.c:240: input buffer: `0000c07f'
error: ./tst-scanf-format-skeleton.c:240: value buffer: `0000c07f'
error: ./tst-scanf-format-skeleton.c:242: input line 1: input data format error
with the two former lines irrelevant. Remove them from output then,
only leaving:
error: ./tst-scanf-format-skeleton.c:242: input line 1: input data format error
No test case added as it's a test case issue in the first place.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
|
|
Reject invalid formatted scanf character data with the 'c' conversion
where there is not enough input available to satisfy the field width
requested. It is required by ISO C that this conversion matches a
sequence of characters of exactly the number specified by the field
width and it is also already documented as such in our own manual:
"It reads precisely the next N characters, and fails if it cannot get
that many."
Currently a matching success is instead incorrectly produced where the
EOF condition is encountered before the required number of characters
has been retrieved, and the characters actually obtained are stored in
the buffer provided.
Add test cases accordingly and remove placeholders from 'c' conversion
input data for the existing scanf tests.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
|
|
The use of the same name for a local variable combined with passing a
pointer to it to a nested macro call causes the wrong 'err' variable to
be updated in 'read_real', because '&err' is only expanded at '*errp'
evaluation. Consequently the variable defined in 'read_real' is set
rather than one in its 'verify_input' caller as it would be the case
should 'read_real' be a function, leading to invalid input such as:
%a:nan:1:3:nan(:
to be accepted.
Address the issue by renaming the 'err' variable in 'verify_input' to
'errx', causing such input to be correctly rejected:
error: ./tst-scanf-format-skeleton.c:242: input line 1: input data format error
No test case added as it's a test case issue in the first place.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
|
|
Reject invalid formatted scanf real input data the significand part of
which is comprised of a hexadecimal prefix followed by a decimal point
only, optionally preceded by a sign. Such data is a prefix of, but not
a matching input sequence and it is required by ISO C to cause a
matching failure.
Currently a matching success is instead incorrectly produced along with
the conversion result of zero, with data up to and including the decimal
point consumed from input.
Technically this change also causes lone . to be rejected early, though
it doesn't change semantics, because unlike 0x. it's not valid input to
'strtod', etc. so it gets rejected at actual conversion time later on
anyway.
Test cases follow as separate changes.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
|
|
Fix a code pattern that repeats across '__vfscanf_internal' where the
remaining field width of 0 is incorrectly interpreted as no width limit,
which in turn results in reading input beyond the limit requested. The
lack of width limit is indicated by the field width of -1 rather than 0,
set earlier on in the function.
The problematic code pattern is used for both integer and floating-point
conversions, but in the former case a corresponding conditional earlier
on prevents the field width from being 0 when executing the pattern. It
does trigger in the latter case, where the decimal point is a multibyte
character or for multibyte digit characters.
Fix the code pattern by using 'width > 0' comparison, and apply the fix
throughout even to code handling integer conversions so as to interpret
the field width consistently and avoid people's confusion even if width
cannot be 0 at those places.
For multibyte digit characters there is an additional issue that causes
code to push back a partially fetched multibyte character multiple times
as execution proceeds through matching data retrieved against individual
digits that have to be rejected due to the field width limit preventing
the rest of the multibyte character from being retrieved. It is because
code relies on 'ungetc' ignoring a request to push back EOF, however in
the out-of-limit field width condition the data held is not EOF but the
previously retrieved character byte instead.
Fix this issue by artificially assigning EOF to the character byte
storage variable where the out-of-limit field width condition prevents
further processing, and also apply the fix throughout except for the
decimal point/thousands separator case, which uses different code.
Add test cases accordingly.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
|
|
tst-freopen4-main.c issues a warning message:
warning: could not remove temporary file: /tmp/tst-freopen4potgti: No such file or directory
since chroot makes generated temporary directories inaccessible. Add
special rules for tst-freopen4.out and tst-freopen64-4.out to remove
the temporary directory in warning message from tst-freopen4 and
tst-freopen64-4.
This partially fixes BZ #33182.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
Reviewed-by: Sam James <sam@gentoo.org>
|
|
Revert commit 6463d4a7b28e5ee3891c34a8a1f0a59c24dfa9de to fix
FAIL: stdio-common/tst-freopen4-mem
FAIL: stdio-common/tst-freopen64-4-mem
This fixes BZ #33254.
Reviewed-by: Sam James <sam@gentoo.org>
|
|
Update tst-freopen4-main.c to call support_capture_subprocess with chroot,
which makes temporary files inaccessible, so that temporary files can be
deleted.
This partially fixes BZ #33182.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
|
|
* stdio-common/stdio_ext.h (__fbufsize, __freading, __fwriting)
(__freadable, __fwritable, __flbf, __fpurge, __fpending, __fsetlocking):
Add __nonnull ((1)) to these functions since they access the FP without
checking if it is NULL.
Signed-off-by: Collin Funk <collin.funk1@gmail.com>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
|
|
Fix a typo in the description, making the wrapper correctly refer to
'sscanf' rather than 'scanf' being tested.
|
|
Make the only place use 'num_digits_len' enumeration constant where 10
is referred literally for a digit index in i18n handling for decimal
integers. No change in code produced.
Reviewed-by: Arjun Shankar <arjun@redhat.com>
|
|
Use __thread variables directly instead. The macros do not save any
typing. It seems unlikely that a future port will lack __thread
variable support.
Some of the __libc_tsd_* variables are referenced from assembler
files, so keep their names. Previously, <libc-tls.h> included
<tls.h>, which in turn included <errno.h>, so a few direct includes
of <errno.h> are now required.
Reviewed-by: Frédéric Bérat <fberat@redhat.com>
|
|
The __printf_fp_buffer_1 issues count_leading_zeros with 0 argument,
which might leads to call __builtin_ctz depending of the ABI.
Replace with stdbit.h function instead.
Checked on x86_64-linux-gnu and i686-linux-gnu.
Reviewed-by: Paul Eggert <eggert@cs.ucla.edu>
|
|
This is required so that fclose, when trying to seek to the right
position after filling the input buffer, does not fail with EINVAL.
This fclose code path only ignores ESPIPE errors.
Reported by Petr Pisar on
<https://bugzilla.redhat.com/show_bug.cgi?id=2358265>.
Fixes commit be6818be31e756398e45f70e2819d78be0961223 ("Make fclose
seek input file to right offset (bug 12724)").
Reviewed-by: Frédéric Bérat <fberat@redhat.com>
|
|
The helper thread may get canceled before the open system
call succeds. Then ThreadData.fd remains zero, and eventually
the xclose call in end_reader_thread fails because descriptor 0
is not open.
Instead, initialize the fd member to -1 (not a valid descriptor)
and close the descriptor only if valid. Do this in a new end_thread
helper routine.
Also add more error checking to close operations.
Fixes commit 95b780c1d0549678c0a244c6e2112ec97edf0839 ("stdio: Add
more setvbuf tests").
|
|
|
|
|
|
Reject invalid formatted scanf real input data the exponent part of
which is comprised of an exponent introducing character, optionally
followed by a sign, and with no actual digits following. Such data is a
prefix of, but not a matching input sequence and it is required by ISO C
to cause a matching failure.
Currently a matching success is instead incorrectly produced along with
the conversion result according to the input significand read and the
exponent of zero, with the significand and the exponent part wholly
consumed from input.
Correct an invalid `tstscanf.c' test accordingly that expects a matching
success for input data provided in the ISO C standard as an example for
a matching failure.
Enable input data that causes test failures without this fix in place.
Reviewed-by: Joseph Myers <josmyers@redhat.com>
|
|
Reject invalid formatted scanf real input data that is comprised of a
hexadecimal prefix, optionally preceded by a sign, and with no actual
digits following owing to the field width restriction in effect. Such
data is a prefix of, but not a matching input sequence and it is
required by ISO C to cause a matching failure.
Currently a matching success is instead incorrectly produced along with
the conversion result of zero, with the prefix wholly consumed from
input. Where the end of input is marked by the end-of-file condition
rather than the field width restriction in effect a matching failure is
already correctly produced.
Enable input data that causes test failures without this fix in place.
Reviewed-by: Joseph Myers <josmyers@redhat.com>
|
|
Reject invalid formatted scanf integer input data that is comprised of a
binary or hexadecimal prefix, optionally preceded by a sign, and with no
actual digits following. Such data is a prefix of, but not a matching
input sequence and it is required by ISO C to cause a matching failure.
Currently a matching success is instead incorrectly produced along with
the conversion result of zero, with the prefix wholly consumed from
input.
Enable input data that causes test failures without this fix in place.
Reviewed-by: Joseph Myers <josmyers@redhat.com>
|
|
Fix the handling of real 'scanf' input such as "+.e" as per BZ #13988
for the i18n case as well, complementing commit 6ecec3b616ae ("Don't
accept exp char without preceding digits in scanf float parsing"), where
the 'e' character is incorrectly consumed from input. Add a test case
matching stdio-common/bug26.c, with bits from localedata/tst-sscanf.c.
Reviewed-by: Joseph Myers <josmyers@redhat.com>
|
|
Wire vsscanf into test infrastructure for formatted scanf input
specifiers.
Reviewed-by: Joseph Myers <josmyers@redhat.com>
|
|
Wire vfscanf into test infrastructure for formatted scanf input
specifiers.
Reviewed-by: Joseph Myers <josmyers@redhat.com>
|
|
Wire vscanf into test infrastructure for formatted scanf input
specifiers.
Reviewed-by: Joseph Myers <josmyers@redhat.com>
|
|
Wire sscanf into test infrastructure for formatted scanf input
specifiers.
Reviewed-by: Joseph Myers <josmyers@redhat.com>
|
|
Wire fscanf into test infrastructure for formatted scanf input
specifiers.
Reviewed-by: Joseph Myers <josmyers@redhat.com>
|
|
Add a collection of tests for formatted scanf input specifiers covering
the b, d, i, o, u, x, and X integer conversions, the a, A, e, E, f, F,
g, and G floating-point conversions, and the [, c, and s character
conversions. Also the hh, h, l, and ll length modifiers are covered
with the integer conversions as are the l and L length modifier with the
floating-point conversions. The tests cover assignment suppressing and
the field width as well, verifying the number of assignments made, the
number of characters consumed and the value assigned.
Add the common test code here as well as test cases for scanf, and then
base Makefile infrastructure plus target-agnostic input data, for the
character conversions and the `char', `short', and `long long' integer
ones, signed and unsigned, with remaining input data and other functions
from the scanf family deferred to subsequent additions.
Keep input data disabled and referring to BZ #12701 for entries that are
currently incorrectly accepted as valid data, such as '0b' or '0x' with
the relevant integer conversions or sequences of an insufficient number
of characters with the c conversion.
Reviewed-by: Joseph Myers <josmyers@redhat.com>
|
|
The 7bb8045ec0 path made the '%n' fortify check ignore EMFILE errors
while trying to open /proc/self/maps, and this added a security
issue where EMFILE can be attacker-controlled thus making it
ineffective for some cases.
The EMFILE failure is reinstated but with a different error
message. Also, to improve the false positive of the hardening for
the cases where no new files can be opened, the
_dl_readonly_area now uses _dl_find_object to check if the
memory area is within a writable ELF segment. The procfs method is
still used as fallback.
Checked on x86_64-linux-gnu and i686-linux-gnu.
Reviewed-by: Arjun Shankar <arjun@redhat.com>
|
|
When an executable is invoked directly, we calculate $ORIGIN by calling
readlink on /proc/self/exe, which the Linux kernel resolves to the
target of any symlinks. However, if an executable is run through ld.so,
we cannot use /proc/self/exe and instead use the path given as an
argument. This leads to a different calculation of $ORIGIN, which is
most notable in that it causes ldd to behave differently (e.g., by not
finding a library) from directly running the program.
To make the behavior consistent, take advantage of the fact that the
kernel also resolves /proc/self/fd/ symlinks to the target of any
symlinks in the same manner, so once we have opened the main executable
in order to load it, replace the user-provided path with the result of
calling readlink("/proc/self/fd/N").
(On non-Linux platforms this resolution does not happen and so no
behavior change is needed.)
The __fd_to_filename requires _fitoa_word and _itoa_word, which for
32-bits pulls a lot of definitions from _itoa.c (due _ITOA_NEEDED
being defined). To simplify the build move the required function
to a new file, _fitoa_word.c.
Checked on x86_64-linux-gnu and i686-linux-gnu.
Co-authored-by: Geoffrey Thomas <geofft@ldpreload.com>
Reviewed-by: Geoffrey Thomas <geofft@ldpreload.com>
Tested-by: Geoffrey Thomas <geofft@ldpreload.com>
|
|
The number of iterations and the length of the string are not high
enough on some systems causing the test to return false-positives.
Testcase stdio-common/tst-fwrite-bz29459.c was fixed in the same way in
1b6f868625403d6b7683af840e87d2b18d5d7731
(Increase the amount of data tested in stdio-common/tst-fwrite-bz29459.c, 2025-02-14)
Testcases stdio-common/tst-fwrite-bz29459.c and stdio-common/tst-fwrite-pipe.c
were introcued in 596a61cf6b51ce2d58b8ca4e1d1f4fdfe1440dbc
(libio: Start to return errors when flushing fwrite's buffer [BZ #29459], 2025-01-28)
|
|
The number of iterations and the length of the string are not high
enough on some systems causing the test to return false-positives.
Fixes: 596a61cf6b (libio: Start to return errors when flushing fwrite's buffer [BZ #29459], 2025-01-28)
Reported-by: Florian Weimer <fweimer@redhat.com>
|
|
Having fixed several bugs relating to flushing of FILE* streams (with
fflush and other operations) and their offsets (both the file position
indicator in the FILE*, and the offset in the underlying open file
description), especially after ungetc but not limited to that case,
add a test that more systematically covers different combinations of
cases for such issues, with 57220 separate scenarios tested (which
include examples of all the five separate fixed bugs), all of which
pass given the five previous bug fixes.
Tested for x86_64.
|
|
As discussed in bug 32535, fflush fails on files opened for reading
using mmap after ungetc. Fix the logic to handle this case and still
compute the file offset correctly.
Tested for x86_64.
|
|
As discussed in bug 32529, fseek fails on files opened for reading
using mmap after ungetc. The implementation of fseek for such files
has an offset computation that's also incorrect after fflush. A
combined fix addresses both problems (with tests for both included as
well) and it seems reasonable to consider them a single bug.
Tested for x86_64.
|
|
As discussed in bug 32369 and required by POSIX, the POSIX feature
fflush (NULL) should flush input files, not just output files. The
POSIX requirement is that "fflush() shall perform this flushing action
on all streams for which the behavior is defined above", and the
definition for input files is for "a stream open for reading with an
underlying file description, if the file is not already at EOF, and
the file is one capable of seeking".
Implement this requirement in glibc. (The underlying flushing
implementation is what deals with avoiding errors for seeking on an
unseekable file.)
Tested for x86_64.
|
|
As discussed in bug 12724 and required by POSIX, before an input file
(based on an underlying seekable file descriptor) is closed, fclose is
sometimes required to seek that file descriptor to the correct offset,
so that any other file descriptors sharing the underlying open file
description are left at that offset (as a motivating example, a script
could call a sequence of commands each of which processes some data
from (seekable) stdin using stdio; fclose needs to do this so that
each successive command can read exactly the data not handled by
previous commands), but glibc fails to do this.
The precise POSIX wording has changed a few times; in the 2024 edition
it's "If the file is not already at EOF, and the file is one capable
of seeking, the file offset of the underlying open file description
shall be set to the file position of the stream if the stream is the
active handle to the underlying file description.".
Add appropriate logic to _IO_new_file_close_it to handle this case. I
haven't made any attempt to test or change things in this area for the
"old" functions.
Note that there was a previous attempt to fix bug 12724, reverted in
commit eb6cbd249f4465b01f428057bf6ab61f5f0c07e3. The fix version here
addresses the original test in that bug report without breaking the
one given in a subsequent comment in that bug report (which works with
glibc before the patch, but maybe was broken by the original fix that
was reverted).
The logic here tries to take care not to seek the file, even to its
newly computed current offset, if at EOF / possibly not the active
handle; even seeking to the current offset would be problematic
because of a potential race (fclose computes the current offset,
another thread or process with the active handle does its own seek,
fclose does a seek (not permitted by POSIX in this case) that loses
the effect of the seek on the active handle in another thread or
process). There are tests included for various cases of being or not
being the active handle, though there aren't tests for the potential
race condition.
Tested for x86_64.
|
|
As discussed in bug 5994 (plus duplicates), POSIX requires fflush
after ungetc to discard pushed-back characters but preserve the file
position indicator. For this purpose, each ungetc decrements the file
position indicator by 1; it is unspecified after ungetc at the start
of the file, and after ungetwc, so no special handling is needed for
either of those cases.
This is fixed with appropriate logic in _IO_new_file_sync. I haven't
made any attempt to test or change things in this area for the "old"
functions; the case of files using mmap is addressed in a subsequent
patch (and there seem to be no problems in this area with files opened
with fmemopen).
Tested for x86_64.
|
|
Test if the file-position is correctly updated when fwrite tries to
flush its internal cache but is not able to completely write all items.
Reviewed-by: DJ Delorie <dj@redhat.com>
|
|
When an error happens, fwrite is expected to return a value that is less
than nmemb. If this error happens while flushing its internal buffer,
fwrite is in a complex scenario: all the data might have been written to
the buffer, indicating a successful copy, but the buffer is expected to
be flushed and it was not.
POSIX.1-2024 states the following about errors on fwrite:
If an error occurs, the resulting value of the file-position indicator
for the stream is unspecified.
The fwrite() function shall return the number of elements successfully
written, which may be less than nitems if a write error is encountered.
With that in mind, this commit modifies _IO_new_file_write in order to
return the total number of bytes written via the file pointer. It also
modifies fwrite in order to use the new information and return the
correct number of bytes written even when sputn returns EOF.
Add 2 tests:
1. tst-fwrite-bz29459: This test is based on the reproducer attached to
bug 29459. In order to work, it requires to pipe stdout to another
process making it hard to reuse test-driver.c. This code is more
specific to the issue reported.
2. tst-fwrite-pipe: Recreates the issue by creating a pipe that is shared
with a child process. Reuses test-driver.c. Evaluates a more generic
scenario.
Co-authored-by: Florian Weimer <fweimer@redhat.com>
Reviewed-by: DJ Delorie <dj@redhat.com>
|
|
Adding some basic tests for fopen, testing different modes, stream
positioning and concurrent read/write operation on files.
Reviewed-by: DJ Delorie <dj@redhat.com>
|
|
mtrace output does not exist
When gawk was not built with MPFR, there's no mtrace output and those
tests FAIL. But we should make them UNSUPPORTED like other
tst-printf-format-* tests in the case.
Signed-off-by: Xi Ruoyao <xry111@xry111.site>
Reviewed-by: Sam James <sam@gentoo.org>
Reviewed-by: Andreas K Hüttel <dilfridge@gentoo.org>
|
