[Patch, 3.3] Fix broken stack-based output stdio_filebuf

[Paolo Carlini]

Hi,

I noticed the problem while working on libstdc++/10063 (3.4)
and I'm proposing the one-liner below for 3.3 (*).

In a nutshell, this code in stdio_filebuf:

      if (__size > 0 && __size < 4)
        {
          // Specify unbuffered.
          _M_buf = _M_unbuf;
          _M_buf_size = __size;
          _M_buf_size_opt = 0;
        }
      else
        {
          _M_buf_size_opt = __size;
          _M_allocate_internal_buffer();
        }

leads to _M_buf_size_opt == 0 not only when actually
_M_buf_size == 0 but also when _M_buf_size < 4 (> 0) and
a small stack-based buffer is in place.

Therefore, at the beginning of _M_really_overflow, this check:

    bool __testunbuffered = _M_file.is_open() && !_M_buf_size_opt;

is *true* for small stack-based buffers and they are not considered
for flush out below:

    if (!__testunbuffered)
      _M_convert_to_external(_M_out_beg,  _M_out_end - _M_out_beg,
                             __elen, __plen);

The simple fix I'm proposing only amends a couple of comments and
changes the check to ... && !_M_buf_size which really means no buffer
to flush out.

Note that the issue is quite hidden since output stdio_filebufs are
usually constructed either zero buffered (when sync_with_stdio true)
or BUFSIZ sized.

Tested x86-linux, Ok?

Thanks,
Paolo.

/////////

(*) As regards mainline, as soon as 27_io reopens I will propose an
unified fix for this issue and libstdc++/10063.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: CL_stack_buf
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20030329/ea9e0dae/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch_stack_buf
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20030329/ea9e0dae/attachment-0001.ksh>