[PATCH v4] libio: Start to return errors when flushing fwrite's buffer [BZ #29459]

[Adhemerval Zanella Netto]

On 01/02/25 09:38, Florian Weimer wrote:
> * Tulio Magno Quites Machado Filho:
> 
>> diff --git a/stdio-common/tst-fwrite-bz29459.c b/stdio-common/tst-fwrite-bz29459.c
>> new file mode 100644
>> index 0000000000..2e8ebc5a08
>> --- /dev/null
>> +++ b/stdio-common/tst-fwrite-bz29459.c
>> @@ -0,0 +1,89 @@
>> +/* Test fwrite against bug 29459.
> 
>> +/* Usually this test reproduces in a few iterations.  However, keep a high
>> +   number of iterations in order to avoid return false-positives due to an
>> +   overwhelmed/slow system.  */
>> +#define ITERATIONS 5000
> 
>> +  /* Ensure the string we send has a new line because we're dealing
>> +     with a lined-buffered stream.  */
>> +  const char *s = "hello\n";
>> +  const size_t len = strlen(s);
> 
> The number of iterations and the length of the written string are too
> small to fill all the buffers in all cases, so we end up with:
> 
>   fprintf(stderr, "Error: fwrite did not return an error\n");
> 
> I suggest to increase both substantially (maybe 500 * 1000 and string
> length 10?).  The total amount of buffering is probably dependent on
> kernel and coreutils versions.

I am seeing some failures on a loaded system as well:

i686-linux-gnu $ cat stdio-common/tst-fwrite-pipe.out
error: tst-fwrite-pipe.c:125: fwrite should have returned an error, but it didn't.

error: 1 test failures

Increasing the number of iterations does not not seems to be a future
proof way to make it reliable.