setvbuf, __fbufsize bug

setvbuf, __fbufsize bug

[Bruno Haible]

With musl-0.9.1: This program shows that after calling setvbuf to make
a stream buffered, it may in fact be unbuffered (__fbufsize returns 0).

This problems leads to a unit test failure in gnulib.


============================= foo.c =============================
#include <stdio.h>
#include <stdio_ext.h>
#include <stdlib.h>

#define TESTFILE "t-fbufmode.tmp"

int
main ()
{
  FILE *fp;
  char buf[5];

  /* Create a file with some contents.  */
  fp = fopen (TESTFILE, "w");
  if (fp == NULL)
    goto skip;
  if (fwrite ("foobarsh", 1, 8, fp) < 8)
    goto skip;
  if (fclose (fp))
    goto skip;

  /* Open it for reading.  */
  fp = fopen (TESTFILE, "r");

  if (setvbuf (fp, NULL, _IONBF, 0))
    goto skip;

  if (__fbufsize (fp) > 0)
    {
      fprintf (stderr, "in unbuffered mode, __fbufsize returns > 0 !\n");
      exit (1);
    }

  if (setvbuf (fp, buf, _IOFBF, 5) == 0)
    {
      if (__fbufsize (fp) == 0)
        {
          fprintf (stderr, "in buffered mode, __fbufsize returns 0 !\n");
          exit (1);
        }
    }

  fclose (fp);

  return 0;

 skip:
  fprintf (stderr, "Skipping test: file operations failed.\n");
  return 77;
}
======================================================================
$ musl-gcc foo.c -Wall
$ ./a.out
in buffered mode, __fbufsize returns 0 !

Re: setvbuf, __fbufsize bug

[Szabolcs Nagy]

* Bruno Haible <bruno@clisp.org> [2012-06-17 21:26:44 +0200]:
> With musl-0.9.1: This program shows that after calling setvbuf to make
> a stream buffered, it may in fact be unbuffered (__fbufsize returns 0).
> 

this is a broken test in gnulib
see c99 7.19.5.6:

"The setvbuf function may be used only after the stream pointed to by
stream has been associated with an open file and before any other operation
(other than an unsuccessful call to setvbuf) is performed on the stream."


> #include <stdio.h>
> #include <stdio_ext.h>
> #include <stdlib.h>
> 
> #define TESTFILE "t-fbufmode.tmp"
> 
> int
> main ()
> {
>   FILE *fp;
>   char buf[5];
> 
>   /* Create a file with some contents.  */
>   fp = fopen (TESTFILE, "w");
>   if (fp == NULL)
>     goto skip;
>   if (fwrite ("foobarsh", 1, 8, fp) < 8)
>     goto skip;
>   if (fclose (fp))
>     goto skip;
> 
>   /* Open it for reading.  */
>   fp = fopen (TESTFILE, "r");
> 
>   if (setvbuf (fp, NULL, _IONBF, 0))
>     goto skip;
> 
>   if (__fbufsize (fp) > 0)
>     {
>       fprintf (stderr, "in unbuffered mode, __fbufsize returns > 0 !\n");
>       exit (1);
>     }
> 
>   if (setvbuf (fp, buf, _IOFBF, 5) == 0)

this call is UB

>     {
>       if (__fbufsize (fp) == 0)
>         {
>           fprintf (stderr, "in buffered mode, __fbufsize returns 0 !\n");
>           exit (1);
>         }
>     }
> 
>   fclose (fp);
> 
>   return 0;
> 
>  skip:
>   fprintf (stderr, "Skipping test: file operations failed.\n");
>   return 77;
> }
> ======================================================================
> $ musl-gcc foo.c -Wall
> $ ./a.out
> in buffered mode, __fbufsize returns 0 !

Re: setvbuf, __fbufsize bug

[Rich Felker]

On Sun, Jun 17, 2012 at 11:07:33PM +0200, Szabolcs Nagy wrote:
> * Bruno Haible <bruno@clisp.org> [2012-06-17 21:26:44 +0200]:
> > With musl-0.9.1: This program shows that after calling setvbuf to make
> > a stream buffered, it may in fact be unbuffered (__fbufsize returns 0).
> > 
> 
> this is a broken test in gnulib
> see c99 7.19.5.6:
> 
> "The setvbuf function may be used only after the stream pointed to by
> stream has been associated with an open file and before any other operation
> (other than an unsuccessful call to setvbuf) is performed on the stream."

Indeed, the test is invoking undefined behavior. musl's setvbuf does
not support any usage but turning off buffering (or switching from
full to line buffering) on a stream that initially had buffering. The
only situation where it's even possible to use setvbuf for another
purpose without invoking UB is to add buffering to stderr (which is
originally unbuffered) or to switch to a larger caller-provided buffer
(which is rarely useful and is the sort of backwards
micro-optimization applications should not be doing these days). If
anyone thinks this usage is sufficiently important that we should
support these uses, please explain why.

Rich