| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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>
|
|
clang-19 shows:
scanf13.c:28:40: error: 'sscanf' may overflow; destination buffer in argument 4 has size 8, but the corresponding specifier may require size 11 [-Werror,-Wfortify-source]
28 | "A%ms%10ms%4m[bcd]%4mcB", &sp1, &sp2, &sp3, &sp4) != 4)
| ^
scanf13.c:94:34: error: 'sscanf' may overflow; destination buffer in argument 3 has size 8, but the corresponding specifier may require size 2049 [-Werror,-Wfortify-source]
94 | if (sscanf (buf, "%2048ms%mc", &sp3, &sp4) != 2)
| ^
scanf13.c:110:61: error: 'sscanf' may overflow; destination buffer in argument 4 has size 8, but the corresponding specifier may require size 1501 [-Werror,-Wfortify-source]
110 | if (sscanf (buf, "%4mc%1500m[dr/]%548m[abc/d]%3mc", &sp1, &sp2, &sp3, &sp4)
| ^
scanf13.c:110:67: error: 'sscanf' may overflow; destination buffer in argument 5 has size 8, but the corresponding specifier may require size 549 [-Werror,-Wfortify-source]
110 | if (sscanf (buf, "%4mc%1500m[dr/]%548m[abc/d]%3mc", &sp1, &sp2, &sp3, &sp4)
clang does have some support to handle 'm' prefix for -Wformat; but it
lacks support for -Wfortify to understand that it is up to libc to
allocate the memory, and uses the pointer size instead to calculate
validity.
|
|
|
|
Followup to 5a96da210c15e18c3c5298dc23a9e2e57691b6c6.
|
|
The issue that was the cause of hang was fixed in upstream.
Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
|
|
Suppress Clang warnings on stdio-common/scanf13.c:
1. Before this commit:
scanf13.c:43:17: error: invalid conversion specifier 'l' [-Werror,-Wformat-invalid-specifier]
43 | "A%mS%10mls%4ml[bcd]%4mCB", &lsp1, &lsp2, &lsp3, &lsp4) != 4)
| ~~~~^
scanf13.c:43:22: error: invalid conversion specifier 'l' [-Werror,-Wformat-invalid-specifier]
43 | "A%mS%10mls%4ml[bcd]%4mCB", &lsp1, &lsp2, &lsp3, &lsp4) != 4)
| ~~~~^
scanf13.c:43:50: error: data argument not used by format string [-Werror,-Wformat-extra-args]
43 | "A%mS%10mls%4ml[bcd]%4mCB", &lsp1, &lsp2, &lsp3, &lsp4) != 4)
| ~~~~~~~~~~~~~~~~~~~~~~~~~~ ^
scanf13.c:145:27: error: invalid conversion specifier 'l' [-Werror,-Wformat-invalid-specifier]
145 | if (sscanf (buf, "%2048mls%mlc", &lsp3, &lsp4) != 2)
| ~~~~~~^
scanf13.c:145:31: error: invalid conversion specifier 'l' [-Werror,-Wformat-invalid-specifier]
145 | if (sscanf (buf, "%2048mls%mlc", &lsp3, &lsp4) != 2)
| ~~~^
scanf13.c:145:43: error: data argument not used by format string [-Werror,-Wformat-extra-args]
145 | if (sscanf (buf, "%2048mls%mlc", &lsp3, &lsp4) != 2)
| ~~~~~~~~~~~~~~ ^
scanf13.c:161:31: error: invalid conversion specifier 'l' [-Werror,-Wformat-invalid-specifier]
161 | if (sscanf (buf, "%4mC%1500ml[dr/]%548ml[abc/d]%3mlc",
| ~~~~~~^
scanf13.c:161:42: error: invalid conversion specifier 'l' [-Werror,-Wformat-invalid-specifier]
161 | if (sscanf (buf, "%4mC%1500ml[dr/]%548ml[abc/d]%3mlc",
| ~~~~~~~~~~^
scanf13.c:161:53: error: invalid conversion specifier 'l' [-Werror,-Wformat-invalid-specifier]
161 | if (sscanf (buf, "%4mC%1500ml[dr/]%548ml[abc/d]%3mlc",
| ~~~~~~~~~~^
scanf13.c:162:15: error: data argument not used by format string [-Werror,-Wformat-extra-args]
161 | if (sscanf (buf, "%4mC%1500ml[dr/]%548ml[abc/d]%3mlc",
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
162 | &lsp1, &lsp2, &lsp3, &lsp4) != 4)
| ^
10 errors generated.
2. With DIAG_IGNORE_NEEDS_COMMENT_CLANG changes in stdio-common/scanf13.c:
scanf13.c:28:40: error: 'sscanf' may overflow; destination buffer in argument 4 has size 8, but the corresponding specifier may require size 11 [-Werror,-Wfortify-source]
28 | "A%ms%10ms%4m[bcd]%4mcB", &sp1, &sp2, &sp3, &sp4) != 4)
| ^
scanf13.c:94:34: error: 'sscanf' may overflow; destination buffer in argument 3 has size 8, but the corresponding specifier may require size 2049 [-Werror,-Wfortify-source]
94 | if (sscanf (buf, "%2048ms%mc", &sp3, &sp4) != 2)
| ^
scanf13.c:110:61: error: 'sscanf' may overflow; destination buffer in argument 4 has size 8, but the corresponding specifier may require size 1501 [-Werror,-Wfortify-source]
110 | if (sscanf (buf, "%4mc%1500m[dr/]%548m[abc/d]%3mc", &sp1, &sp2, &sp3, &sp4)
| ^
scanf13.c:110:67: error: 'sscanf' may overflow; destination buffer in argument 5 has size 8, but the corresponding specifier may require size 549 [-Werror,-Wfortify-source]
110 | if (sscanf (buf, "%4mc%1500m[dr/]%548m[abc/d]%3mc", &sp1, &sp2, &sp3, &sp4)
| ^
4 errors generated.
Co-Authored-By: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
Reviewed-by: Sam James <sam@gentoo.org>
|
|
Since Clang doesn't support
DIAG_IGNORE_NEEDS_COMMENT (11, "-Wformat=");
and for unknown reasons, it doesn't warn the %#m specifier, suppress
-Wformat only for gcc in tst-sprintf-errno.c.
Co-Authored-By: H.J. Lu <hjl.tools@gmail.com>
Reviewed-by: Sam James <sam@gentoo.org>
|
|
Clang issues the following warning:
tst-vfprintf-width-i18n.c:51:34: error: invalid conversion specifier '1'
[-Werror,-Wformat-invalid-specifier]
TEST_COMPARE (sprintf (buf, "%I16d", 12345), 16);
~~^
since it does not how to handle %I.
Reviewed-by: Sam James <sam@gentoo.org>
|
|
clang does not support 'I' specifier and handles it as a 'length
modifier'.
Reviewed-by: Sam James <sam@gentoo.org>
|
|
clang does not handle %Z on print, and just suppressing
-Wformat-invalid-specifier might trigger another warning for extra
arguments (since %Z is ignored). So suppress -Wformat-extra-args
as well.
For tst-fphex.c a heavy hammer is used since the printf is more
complex and clang throws a more generic warning.
Reviewed-by: Sam James <sam@gentoo.org>
|
|
Suppress the following -Wgnu-folding-constant and -Wliteral-conversion
warnings from Clang:
tst-unlockedio.c:35:12: error: variable length array folded to constant array as an extension [-Werror,-Wgnu-folding-constant]
35 | char buf[strlen (blah) + 1];
| ^~~~~~~~~~~~~~~~~
tst-unlockedio.c:63:36: error: implicit conversion from 'double' to
'size_t' (aka 'unsigned long') changes value from -0 to 0
[-Werror,-Wliteral-conversion]
|| fwrite_unlocked (blah, 0, -0.0, fp) != 0
~~~~~~~~~~~~~~~ ^~~~
tst-unlockedio.c:61:33: error: implicit conversion from 'double' to
'size_t' (aka 'unsigned long') changes value from 0.25 to 0
[-Werror,-Wliteral-conversion]
|| fwrite_unlocked (--cp, 0.25, 16, fp) != 0
~~~~~~~~~~~~~~~ ^~~~
tst-unlockedio.c:59:37: error: implicit conversion from 'double' to
'size_t' (aka 'unsigned long') changes value from 0.25 to 0
[-Werror,-Wliteral-conversion]
|| fwrite_unlocked (cp++, 16, 0.25, fp) != 0
~~~~~~~~~~~~~~~ ^~~~
tst-unlockedio.c:116:34: error: implicit conversion from 'double' to
'size_t' (aka 'unsigned long') changes value from -0 to 0
[-Werror,-Wliteral-conversion]
|| fread_unlocked (buf, 0, -0.0, fp) != 0
~~~~~~~~~~~~~~ ^~~~
tst-unlockedio.c:114:32: error: implicit conversion from 'double' to
'size_t' (aka 'unsigned long') changes value from 0.25 to 0
[-Werror,-Wliteral-conversion]
|| fread_unlocked (--wp, 0.25, 16, fp) != 0
~~~~~~~~~~~~~~ ^~~~
tst-unlockedio.c:112:36: error: implicit conversion from 'double' to
'size_t' (aka 'unsigned long') changes value from 0.25 to 0
[-Werror,-Wliteral-conversion]
|| fread_unlocked (wp++, 16, 0.25, fp) != 0
~~~~~~~~~~~~~~ ^~~~
Co-Authored-By: H.J. Lu <hjl.tools@gmail.com>
Reviewed-by: Sam James <sam@gentoo.org>
|
|
Use
__attribute__ ((optnone))
instead of
__attribute__ ((optimize ("-O0")))
to disable optimization for Clang.
Co-Authored-By: H.J. Lu <hjl.tools@gmail.com>
Reviewed-by: Sam James <sam@gentoo.org>
|
|
Clang 19 takes a very long time, it ran more than 27 minutes on Intel Core
i7-1195G7 before the process was killed, to compile bug28.c:
https://github.com/llvm/llvm-project/issues/120462
Exclude it when Clang is used for testing.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
Reviewed-by: Sam James <sam@gentoo.org>
|
|
The C standard requires that ungetc guarantees at least one pushback,
but the malloc call to allocate the pushback buffer could fail, thus
violating that requirement. Fix this by adding a single byte pushback
buffer in the FILE struct that the pushback can fall back to if malloc
fails.
The side-effect is that if the initial malloc fails and the 1-byte
fallback buffer is used, future resizing (if it succeeds) will be
2-bytes, 4-bytes and so on, which is suboptimal but it's after a malloc
failure, so maybe even desirable.
A future optimization here could be to have the pushback code use the
single byte buffer first and only fall back to malloc for subsequent
calls.
Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
Reviewed-by: Maciej W. Rozycki <macro@redhat.com>
|
|
GCC 4.9 issues an error for copysign in initializer:
In file included from tst-printf-format-p-double.c:20:0:
tst-printf-format-skeleton-double.c:29:3: error: initializer element is not a constant expression [-Werror]
{ -HUGE_VAL, -DBL_MAX, -DBL_MIN, copysign (0, -1), -NAN, NAN, 0, DBL_MIN,
^
since it can't fold "copysign (0, -1)". Replace copysign (0,-1) with -0.0.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
|
|
Replace 0 by NULL and {0} by {}.
Omit a few cases that aren't so trivial to fix.
Link: <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117059>
Link: <https://software.codidact.com/posts/292718/292759#answer-292759>
Signed-off-by: Alejandro Colomar <alx@kernel.org>
|
|
Nameless function parameters have only been added to ISO C with the C23
revision of the language standard. Give names to the unused parameters
of the stub 'dladdr' implementation then so as to make compilation happy
with the earlier language definitions, fixing errors such as:
tst-printf-format-skeleton.c:374:9: error: parameter name omitted
374 | dladdr (const void *, Dl_info *)
reported by older compilers.
Reviewed-by: Florian Weimer <fweimer@redhat.com>
|
|
Wire vsnprintf into test infrastructure for formatted printf output
specifiers.
Reviewed-by: DJ Delorie <dj@redhat.com>
|
|
Wire vsprintf into test infrastructure for formatted printf output
specifiers.
Reviewed-by: DJ Delorie <dj@redhat.com>
|
|
Wire vfprintf into test infrastructure for formatted printf output
specifiers.
Reviewed-by: DJ Delorie <dj@redhat.com>
|
|
Wire vdprintf into test infrastructure for formatted printf output
specifiers.
Reviewed-by: DJ Delorie <dj@redhat.com>
|
|
Wire vasprintf into test infrastructure for formatted printf output
specifiers.
Owing to mtrace logging these tests take amounts of time to complete
similar to those of corresponding asprintf tests, so set timeouts for
the tests accordingly, with a global default for all the vasprintf
tests, and then individual higher settings for double and long double
tests each.
Reviewed-by: DJ Delorie <dj@redhat.com>
|
|
Wire vprintf into test infrastructure for formatted printf output
specifiers.
Reviewed-by: DJ Delorie <dj@redhat.com>
|
|
Wire snprintf into test infrastructure for formatted printf output
specifiers.
Reviewed-by: DJ Delorie <dj@redhat.com>
|
|
Wire sprintf into test infrastructure for formatted printf output
specifiers.
Reviewed-by: DJ Delorie <dj@redhat.com>
|
|
Wire fprintf into test infrastructure for formatted printf output
specifiers.
Reviewed-by: DJ Delorie <dj@redhat.com>
|
|
Wire dprintf into test infrastructure for formatted printf output
specifiers.
Reviewed-by: DJ Delorie <dj@redhat.com>
|
|
Wire asprintf into test infrastructure for formatted printf output
specifiers.
Owing to mtrace logging of lots of memory allocation calls these tests
take a considerable amount of time to complete, except for the character
conversion, taking from 00m20s for 'tst-printf-format-as-s --direct s',
through 01m10s and 03m53s for 'tst-printf-format-as-char --direct i' and
'tst-printf-format-as-double --direct f' respectively, to 19m24s for
'tst-printf-format-as-ldouble --direct f', all in standalone execution
from NFS on a RISC-V FU740@1.2GHz system and with output redirected over
100Mbps network via SSH. It is with the skeleton's stub implementation
of dladdr(3); execution times with regular dladdr(3) are up to over
twice longer.
Set timeouts for the tests accordingly then, with a global default for
all the asprintf tests, and then individual higher settings for double
and long double tests each.
Reviewed-by: DJ Delorie <dj@redhat.com>
|
|
This is a collection of tests for formatted printf output specifiers
covering the d, i, o, u, x, and X integer conversions, the e, E, f, F,
g, and G floating-point conversions, the c character conversion, and the
s string conversion. Also the hh, h, l, and ll length modifiers are
covered with the integer conversions as is the L length modifier with
the floating-point conversions.
The -, +, space, #, and 0 flags are iterated over, as permitted by the
conversion handled, in tuples of 1..5, including tuples with repetitions
of 2, and combined with field width and/or precision, again as permitted
by the conversion. The resulting format string is then used to produce
output from respective sets of input data corresponding to the specific
conversion under test. POSIX extensions beyond ISO C are not used.
Output is produced in the form of records which include both the format
string (and width and/or precision where given in the form of separate
arguments) and the conversion result, and is verified with GNU AWK using
the format obtained from each such record against the reference value
also supplied, relying on the fact that GNU AWK has its own independent
implementation of format processing, striving to be ISO C compatible.
In the course of implementation I have determined that in the non-bignum
mode GNU AWK uses system sprintf(3) for the floating-point conversions,
defeating the objective of doing the verification against an independent
implementation. Additionally the bignum mode (using MPFR) is required
to correctly output wider integer and floating-point data. Therefore
for the conversions affected the relevant shell scripts sanity-check AWK
and terminate with unsupported status if the bignum mode is unavailable
for floating-point data or where data is output incorrectly.
The f and F floating-point conversions are build-time options for GNU
AWK, depending on the environment, so they are probed for before being
used. Similarly the a and A floating-point conversions, however they
are currently not used, see below. Also GNU AWK does not handle the b
or B integer conversions at all at the moment, as at 5.3.0. Support for
the a, A, b, and B conversions can however be easily added following the
approach taken for the f and F conversions.
Output produced by gawk for the a and A floating-point conversions does
not match one produced by us: insufficient precision is used where one
hasn't been explicitly given, e.g. for the negated maximum finite IEEE
754 64-bit value of -1.79769313486231570814527423731704357e+308 and "%a"
format we produce -0x1.fffffffffffffp+1023 vs gawk's -0x1.000000p+1024
and a different exponent is chosen otherwise, such as with "%.a" where
we output -0x2p+1023 vs gawk's -0x1p+1024 for the same value, or "%.20a"
where -0x1.fffffffffffff0000000p+1023 is our output, but gawk produces
-0xf.ffffffffffff80000000p+1020 instead. Consequently I chose not to
include a and A conversions in testing at this time.
And last but not least there are numerous corner cases that GNU AWK does
not handle correctly, which are worked around by explicit handling in
the AWK script. These are in particular:
- extraneous leading 0 produced for the alternative form with the o
conversion, e.g. { printf "%#.2o", 1 } produces "001" rather than
"01",
- unexpected 0 produced where no characters are expected for the input
of 0 and the alternative form with the precision of 0 and the integer
hexadecimal conversions, e.g. { printf "%#.x", 0 } produces "0" rather
than "",
- missing + character in the non-bignum mode only for the input of 0
with the + flag, precision of 0 and the signed integer conversions,
e.g. { printf "%+.i", 0 } produces "" rather than "+",
- missing space character in the non-bignum mode only for the input of 0
with the space flag, precision of 0 and the signed integer
conversions, e.g. { printf "% .i", 0 } produces "" rather than " ",
- for released gawk versions of up to 4.2.1 missing - character for the
input of -NaN with the floating-point conversions, e.g. { printf "%e",
"-nan" }' produces "nan" rather than "-nan",
- for released gawk versions from 5.0.0 onwards + character output for
the input of -NaN with the floating-point conversions, e.g. { printf
"%e", "-nan" }' produces "+nan" rather than "-nan",
- for released gawk versions from 5.0.0 onwards + character output for
the input of Inf or NaN in the absence of the + or space flags with
the floating-point conversions, e.g. { printf "%e", "inf" }' produces
"+inf" rather than "inf",
- for released gawk versions of up to 4.2.1 missing + character for the
input of Inf or NaN with the + flag and the floating-point
conversions, e.g. { printf "%+e", "inf" }' produces "inf" rather than
"+inf",
- for released gawk versions of up to 4.2.1 missing space character for
the input of Inf or NaN with the space flag and the floating-point
conversions, e.g. { printf "% e", "nan" }' produces "nan" rather than
" nan",
- for released gawk versions from 5.0.0 onwards + character output for
the input of Inf or NaN with the space flag and the floating-point
conversions, e.g. { printf "% e", "inf" }' produces "+inf" rather than
" inf",
- for released gawk versions from 5.0.0 onwards the field width is
ignored for the input of Inf or NaN and the floating-point
conversions, e.g. { printf "%20e", "-inf" }' produces "-inf" rather
than " -inf",
NB for released gawk versions of up to 4.2.1 floating-point conversion
issues apply to the bignum mode only, as in the non-bignum mode system
sprintf(3) is used. As from version 5.0.0 specialized handling has been
added for [-]Inf and [-]NaN inputs and the issues listed apply to both
modes. The '--posix' flag makes gawk versions from 5.0.0 onwards avoid
the issue with field width and the + character unconditionally output
for the input of Inf or NaN, however not the remaining issues and then
the 'gensub' function is not supported in the POSIX mode, so to go this
path I deemed not worth it.
Each test completes within single seconds except for the long double
one. There the F/f formats produce a large number of digits, which
appears to be computationally intensive and CPU-bound. Standalone
execution time for 'tst-printf-format-p-ldouble --direct f' is in the
range of 00m36s for POWER9@2.166GHz and 09m52s for FU740@1.2GHz and
output redirected locally to /dev/null, and 10m11s for FU740 and output
redirected over 100Mbps network via SSH to /dev/null, so the throughput
of the network adds very little (~3.2% in this case) to the processing
time. This is with IEEE 754 quad.
So I have scaled the timeout for 'tst-printf-format-skeleton-ldouble'
accordingly. Regardless, following recent practice the test has been
added to the standard rather than extended set. However, unlike most
of the remaining tests it has been split by the conversion specifier,
so as to allow better parallelization of this long-running test. As
a side effect this lets the test report the unsupported status for the
F/f conversions where applicable, so 'tst-printf-format-p-double' has
been split for consistency as well.
Only printf itself is handled at the moment, but the infrastructure
provides for all the printf family functions to be verified, changes
for which to be supplied separately. The complication around having
some tests iterating over all the relevant conversion specifiers and
other verifying conversion specifiers individually combined with
iterating over printf family functions has hit a peculiarity in GNU
make where the use of multiple targets with a pattern rule is handled
differently from such use with an ordinary rule. Consequently it
seems impossible to bulk-define a pattern rule using '$(foreach ...)',
where each target would simply trigger the recipe according to the
pattern and matching dependencies individually (such a rule does work,
but implies all targets to be updated with a single recipe execution).
Therefore as a compromise a single single-target pattern rule has been
defined that has listed all the conversion-specific scripts and all the
test executables as dependencies. Consequently tests will be rerun in
the absence of changes to their actual sources or scripts whenever an
unrelated file has changed that has been listed. Also all the formatted
printf output tests will always be built whenever any single one is to
be run. This only affects test development and not test runs in the
field, though it does change the order of execution of the individual
steps and also acts as a Makefile barrier in parallel runs. As the
execution time dominates the compilation time for these tests it is not
seen as a serious shortcoming.
As pointed out by Florian Weimer <fweimer@redhat.com> the malloc tracing
facility can take a substantial amount of time in calling dladdr(3) to
determine the caller's location. This is not needed by the verification
made with these tests, so I chose to interpose the symbol with a stub
implementation that always fails in the shared skeleton. We have total
control over the test environment, so I think it is a safe and minimal
impact approach. If there's ever anything else added to the tests that
would actually rely on dladdr(3) returning usable results, only then we
can think of a different approach.
Reviewed-by: DJ Delorie <dj@redhat.com>
|
|
The scanf family of functions like sscanf and fscanf currently
ignore nan() and nan(n-char-sequence). This happens because
__vfscanf_internal only checks for 'nan'.
This commit adds support for all valid nan types i.e. nan, nan()
and nan(n-char-sequence), where n-char-sequence can be
[a-zA-Z0-9_]+, thus fixing the bug 30647. Any other representation
of NaN should result in conversion error.
New tests are also added to verify the correct parsing of NaN types for
float, double and long double formats.
Signed-off-by: Avinal Kumar <avinal.xlvii@gmail.com>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
|
|
Fix stdio-common/Makefile:
@@ -224,12 +224,12 @@
tst-freopen4 \
tst-freopen5 \
tst-freopen6 \
+ tst-freopen7 \
tst-freopen64-2 \
tst-freopen64-3 \
tst-freopen64-4 \
tst-freopen64-6 \
tst-freopen64-7 \
- tst-freopen7 \
tst-fseek \
tst-fwrite \
tst-fwrite-memstrm \
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
|
|
Add tests of freopen adding or removing "c" (non-cancelling I/O) from
the mode string (so completing my planned tests of freopen with
different features used in the mode strings). Note that it's in the
nature of the uncertain time at which cancellation might act (possibly
during freopen, possibly during subsequent reads) that these can leak
memory or file descriptors, so these do not include leak tests.
Tested for x86_64.
|
|
The -Wp does not work properly if the compiler is configured to enable
fortify by default, since it bypasses the compiler driver (which defines
the fortify flags in this case).
This patch is similar to the one used on Ubuntu [1].
I checked with a build for x86_64-linux-gnu, i686-linux-gnu,
aarch64-linux-gnu, s390x-linux-gnu, and riscv64-linux-gnu with
gcc-13 that enables the fortify by default.
Co-authored-by: Matthias Klose <matthias.klose@canonical.com>
[1] https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/glibc/tree/debian/patches/ubuntu/fix-fortify-source.patch
Reviewed-by: DJ Delorie <dj@redhat.com>
|
|
Exercises fwrite's internal buffer when doing a file operation.
The new test, exercises 2 overflow behaviors:
1. Call fwrite multiple times making usage of fwrite's internal buffer.
The total number of bytes written is larger than fwrite's internal
buffer, forcing an automatic flush.
2. Call fwrite a single time with an amount of data that is larger than
fwrite's internal buffer.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
|
