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
1b6f868625
(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 596a61cf6b
(libio: Start to return errors when flushing fwrite's buffer [BZ #29459], 2025-01-28)
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>
Stefan Liebler
Tulio Magno Quites Machado Filho