[PATCH v6 1/1] stdio-common: Add more tests of the setvbuf()function.

[Maciej W. Rozycki]

On Tue, 12 Nov 2024, Nick Clifton wrote:

> diff --git a/stdio-common/tst-setvbuf2.c b/stdio-common/tst-setvbuf2.c
> new file mode 100644
> index 0000000000..cc0c086e7d
> --- /dev/null
> +++ b/stdio-common/tst-setvbuf2.c
> @@ -0,0 +1,70 @@
[...]
> +/* Check that the standard streams (stdout and stderr) can be set to
> +   unbuffered.  Note - the POSIX standard indicates that setting the
> +   buffering on a stream might not work.  It states:
> +     
> +     The setvbuf( ) function may be used after the stream
> +     pointed to by stream is associated with an open file
> +     but before any other operation (other than an unsuccessful
> +     call to setvbuf( )) is performed on the stream.
> +
> +  Hence if messages have already been written to stdout and/or stderr
> +  before this code is executed then we may not be able to change
> +  the buffering.  The standard does not provide a way to detect if
> +  this has happened, so we have to hope for the best.  */

 A minor indentation issue here: one leading space has been lost across 
the last paragraph.  Similarly in the remaining files where a paragraph 
follows a quotation.

> +  /* The theory was that this test would be run with stdout and stderr redirected
> +     into a single file.  Then writes to stdout and stderr would be performed
> +     with and without newlines and finally the contents of the file would be
> +     examined to find out if any buffering has taken place.  Unfortunately whilt
> +     this works when run by hand, or from a makefile running on an ordinary
> +     terminal, it does not work when run by Linaro's CI system.

 Has the root cause been found?  I suppose you might be able to recreate 
an environment to fiddle with locally similar to Linaro's CI by running 
the test case via the daemon(1) utility.

> +     There is no way to distinguish Linaro's execution environment from a normal
> +     execution environment.  (Testing that stdout/stderr are attached to
> +     terminals does not work, since they are not - they are attached to an output
> +     file: tst-setvbuf.out).  All of which means that in the end we cannot test
> +     the behaviour of buffering when writing to standard files.  (See
> +     tst-setvuf4.c and tst-setvbuf5.c for tests that do work when writing to disk
> +     based files).

 Have you tried checking what /dev/tty (or the result of ctermid(3) if you 
want it portable) refers to?  That's the usual way to find out whether a 
program runs with a controlling terminal regardless of any redirections.  
Though I find it unclear why having or not having a controlling terminal 
would affect buffering for stream I/O with an unrelated regular file.

 NB may you please keep the comments within 79 columns as per both GNU 
Coding Standards and our own convention?

  Maciej