aboutsummaryrefslogtreecommitdiff
path: root/stdio-common
AgeCommit message (Collapse)AuthorFilesLines
2025-12-09Handle clang -Wignored-attributes on weak aliasesAdhemerval Zanella1-2/+0
Clang issues a warning for double alias redirection, indicating that thei original symbol is used even if a weak definition attempts to override it. For instance, in the construction: int __internal_impl (...) {} weak_alias (__internal_impl, external_impl); #if SOMETHING weak_alias (external_impl, another_external_impl) #endif Clang warns that another_external_impl always resolves to __internal_impl, even if external_impl is a weak reference. Using the internal symbol for both aliases resolves this warning. This issue also occurs with certain libc_hidden_def usage: int __internal_impl (...) {} weak_alias (__internal_impl, __internal_alias) libc_hidden_weak (__internal_alias) In this case, using a strong_alias is sufficient to avoid the warning (since the alias is internal, there is no need to use a weak alias). However, for the constructions like: int __internal_impl (...) {} weak_alias (__internal_impl, __internal_alias) libc_hidden_def (__internal_alias) weak_alias (__internal_impl, external_alias) libc_hidden_def (external_alias) Clang warns that the internal external_alias will always resolve to __GI___internal_impl, even if a weak definition of __GI_internal_impl is overridden. For this case, a new macro named static_weak_alias is used to create a strong alias for SHARED, or a weak_alias otherwise. With these changes, there is no need to check and enable the -Wno-ignored-attributes suppression when using clang. Checked with a build on affected ABIs, and a full check on aarch64, armhf, i686, and x86_64. Reviewed-by: Sam James <sam@gentoo.org>
2025-11-26stdlib: Remove longlong.hAdhemerval Zanella2-4/+0
The gmp-arch.h now provides all the required definitions. Reviewed-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
2025-11-25Add gmp-arch and udiv_qrnndAdhemerval Zanella2-6/+8
To enable “longlong.h” removal, the udiv_qrnnd is moved to a gmp-arch.h file. It allows each architecture to implement its own arch-specific optimizations. The generic implementation now uses a static inline, which provides better type checking than the GNU extension to cast the asm constraint (and it works better with clang). Most of the architecture uses the generic implementation, which is expanded from a macro, except for alpha, x86, m68k, sh, and sparc. I kept that alpha, which uses out-of-the-line implementations and x86, where there is no easy way to use the div{q} instruction from C code. For the rest, the compiler generates good enough code. The hppa also provides arch-specific implementations, but they are not routed in “longlong.h” and thus never used. Reviewed-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
2025-11-13htl: move {,_IO_}f{,un,try}lockfile implementation into libcSamuel Thibault2-0/+2
2025-10-30Cleanup some recently added whitespace.Collin Funk2-2/+2
Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
2025-10-29Supress unused command arguments warning with clangAdhemerval Zanella1-4/+4
clang 20 issues an warning for the unused '-c' argument used to create errlist-data-aux-shared.S, errlist-data-aux.S, siglist-aux-shared.S, and siglist-aux.S. Filter out the '-c' from the $(compile-command.c). Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
2025-10-29Annotate swtich fall-throughAdhemerval Zanella2-3/+3
The clang default to warning for missing fall-through and it does not support all comment-like annotation that gcc does. Use C23 [[fallthrough]] annotation instead. proper attribute instead. Reviewed-by: Collin Funk <collin.funk1@gmail.com>
2025-10-21stdio: Fix -Wtautological-constant-out-of-range-compare on clangAdhemerval Zanella1-1/+6
clang emits an error while building vfprintf-internal for default case: error: result of comparison of constant 255 with expression of type 'char' is always true [-Werror,-Wtautological-constant-out-of-range-compare] if (spec <= UCHAR_MAX The test is indeed not required for default non-wide build. Reviewed-by: Collin Funk <collin.funk1@gmail.com>
2025-10-21Suppress -Wmaybe-uninitialized only for gccAdhemerval Zanella1-1/+1
The warning is not supported by clang. Reviewed-by: Sam James <sam@gentoo.org>
2025-10-20Make <inttypes.h> printf macros narrow arguments (bug 31470)Joseph Myers2-0/+94
A late change in C23, the resolution to CD2 comment GB-108, specified that <inttypes.h> macros such as PRId8 expand to formats such that, when an argument is passed in the promoted type that isn't representable in the original type such as int8_t corresponding to the format, it gets converted to that type before printing. (Previously, the proper handling of such arguments was unclear; the case of direct use of formats such as %hhd was clarified earlier in C23 development, and had been fixed in glibc in 2006.) Implement the change to use formats such as "hhd" for the affected macros, with associated tests. Tested for x86_64 and x86.
2025-09-05libio: Define AT_RENAME_* with the same tokens as LinuxFlorian Weimer1-0/+6
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>
2025-09-05testsuite: Update tests for 'xfclose' useMaciej W. Rozycki2-0/+2
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>
2025-09-05testsuite: Update tests for 'xfmemopen' useMaciej W. Rozycki3-11/+9
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>
2025-09-01Tests: Create files with mode 0666, not 0777 (bug 33171)Florian Weimer1-4/+3
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>
2025-08-23stdio-common: Convert macros across scanf input specifier testsMaciej W. Rozycki4-392/+402
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>
2025-08-23stdio-common: Adjust header inclusion in scanf input specifier testsMaciej W. Rozycki98-84/+14
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>
2025-08-23stdio-common: Include correct skeleton in scanf input specifier testsMaciej W. Rozycki70-70/+70
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>
2025-08-23stdio-common: Fix bad NaN crash in scanf input specifier tests [BZ #32857]Maciej W. Rozycki1-31/+33
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>
2025-08-23stdio-common: Fix a crash in scanf input specifier tests [BZ #32857]Maciej W. Rozycki1-5/+5
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>
2025-08-23stdio-common: Fix error reporting in scanf input specifier testsMaciej W. Rozycki1-3/+4
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>
2025-08-23stdio-common: Reject insufficient character data in scanf [BZ #12701]Maciej W. Rozycki4-22/+180
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>
2025-08-11stdio-common: Fix macro parameter shadowing in scanf input specifier testsMaciej W. Rozycki1-5/+5
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>
2025-08-11stdio-common: Reject significands w/o digits in scanf [BZ #12701]Maciej W. Rozycki1-5/+5
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>
2025-08-11stdio-common: Don't read real input beyond the field width in scanfMaciej W. Rozycki1-11/+20
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>
2025-08-05tst-freopen4: Remove temporary directory from warning messageH.J. Lu1-0/+24
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>
2025-08-05Revert "tst-freopen4-main.c: Call support_capture_subprocess with chroot"H.J. Lu1-30/+14
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>
2025-08-04tst-freopen4-main.c: Call support_capture_subprocess with chrootH.J. Lu1-14/+30
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>
2025-06-02stdio-common: Add nonnull attribute to stdio_ext.h functions.Collin Funk1-9/+9
* 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>
2025-05-30stdio-common: Correct 'sscanf' test feature wrapper descriptionMaciej W. Rozycki1-1/+1
Fix a typo in the description, making the wrapper correctly refer to 'sscanf' rather than 'scanf' being tested.
2025-05-29stdio-common: Consistently use 'num_digits_len' in 'vfscanf'Maciej W. Rozycki1-1/+1
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>
2025-05-16Remove <libc-tsd.h>Florian Weimer1-0/+1
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>
2025-04-28stdio: Remove UB on printf_fpAdhemerval Zanella1-9/+9
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>
2025-04-14libio: Synthesize ESPIPE error if lseek returns 0 after reading bytesFlorian Weimer2-0/+51
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>
2025-04-08stdio-common: In tst-setvbuf2, close helper thread descriptor only if openedFlorian Weimer1-18/+21
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").
2025-04-02stdio: fix hurd link for tst-setvbuf2DJ Delorie1-1/+2
2025-04-01stdio: Add more setvbuf testsDJ Delorie3-1/+1041
2025-03-28stdio-common: Reject real data w/o exponent digits in scanf [BZ #12701]Maciej W. Rozycki2-3/+6
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>
2025-03-28stdio-common: Reject significand prefixes in scanf [BZ #12701]Maciej W. Rozycki1-1/+6
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>
2025-03-28stdio-common: Reject integer prefixes in scanf [BZ #12701]Maciej W. Rozycki13-937/+947
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>
2025-03-28stdio-common: Also reject exp char w/o significand in i18n scanf [BZ #13988]Maciej W. Rozycki1-3/+9
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>
2025-03-28stdio-common: Add tests for formatted vsscanf input specifiersMaciej W. Rozycki16-1/+386
Wire vsscanf into test infrastructure for formatted scanf input specifiers. Reviewed-by: Joseph Myers <josmyers@redhat.com>
2025-03-28stdio-common: Add tests for formatted vfscanf input specifiersMaciej W. Rozycki16-1/+345
Wire vfscanf into test infrastructure for formatted scanf input specifiers. Reviewed-by: Joseph Myers <josmyers@redhat.com>
2025-03-28stdio-common: Add tests for formatted vscanf input specifiersMaciej W. Rozycki16-1/+345
Wire vscanf into test infrastructure for formatted scanf input specifiers. Reviewed-by: Joseph Myers <josmyers@redhat.com>
2025-03-28stdio-common: Add tests for formatted sscanf input specifiersMaciej W. Rozycki16-1/+382
Wire sscanf into test infrastructure for formatted scanf input specifiers. Reviewed-by: Joseph Myers <josmyers@redhat.com>
2025-03-28stdio-common: Add tests for formatted fscanf input specifiersMaciej W. Rozycki16-1/+338
Wire fscanf into test infrastructure for formatted scanf input specifiers. Reviewed-by: Joseph Myers <josmyers@redhat.com>
2025-03-25stdio-common: Add tests for formatted scanf input specifiersMaciej W. Rozycki59-0/+15485
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>
2025-03-21debug: Improve '%n' fortify detection (BZ 30932)Adhemerval Zanella2-15/+22
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>
2025-03-13elf: Canonicalize $ORIGIN in an explicit ld.so invocation [BZ 25263]Adhemerval Zanella3-43/+62
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>
2025-02-24Increase the amount of data tested in stdio-common/tst-fwrite-pipe.cStefan Liebler1-2/+2
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)
2025-02-14Increase the amount of data tested in stdio-common/tst-fwrite-bz29459.cTulio Magno Quites Machado Filho1-2/+2
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>