[Patch] Fix libstdc++/9533

[Paolo Carlini]

Nathan Myers wrote:

>On Mon, Mar 03, 2003 at 07:27:14PM +0100, Paolo Carlini wrote:
>
>>the below, which is the result of today's exchanges with P?tur,
>>fixes the problem by setting O_NONBLOCK only for initializing the
>>buffer, otherwise leaving O_NONBLOCK clear, as explained by Nathan.
>>...
>>+
>>+  void
>>+#if defined (F_SETFL) && defined (F_GETFL) && defined (O_NONBLOCK)
>>+  __basic_file<char>::no_block(int& __fdflags)
>>+#else
>>+  __basic_file<char>::no_block(int&)
>>+#endif
>>+  {
>>+    if (this->is_open())
>>+      {
>>+#if defined (F_SETFL) && defined (F_GETFL) && defined (O_NONBLOCK)
>>+	__fdflags = fcntl(this->fd(), F_GETFL);
>>+	fcntl(this->fd(), F_SETFL, O_NONBLOCK);
>>+#endif
>>+      }
>>+  }
>>
>
>This looks incomplete to me.  I would expect the if statement to be 
>in the #if block.  (Likewise in block().)
>
Ok. However, when the #if is false, things are quite broken anyway,
but we have to keep this possibility open (Danny Smith introduced the
#if def)

>  Also, I would expect to 
>see (O_NONBLOCK | __fdflags) passed to fcntl.
>
Does it make a difference? I adapted the whole scheme from an example
somewhere ;) and fcntl(this->fd(), F_SETFL, O_NONBLOCK); was already
in the code, instead.

>  Why return the flags
>via int& instead of by function return?
>
Ok. In fact was not sure about this design choices.

>  fcntl should be called as 
>::fcntl.  (Likewise other system calls.  Do we have a policy yet?)
>
No, sadly :( I think that if we use ::fcntl here it's the _first_ example
of the syntax!

>Finally, mustn't these members' names be uglified, e.g. _M_no_block
>etc.?
>
The other members of __basic_file<char> aren't and I followed the
existing practice. Should we change all of them?

>It's not clear to me why the non-blocking read is needed at all,
>
Honestly, it's not completely clear to me too.
One thing is sure: the testcase which I posted earlier today breaks
otherwise:

    http://gcc.gnu.org/ml/libstdc++/2003-03/msg00008.html

And 9533 testcase doesn't display the prompt at all.

>or why we're reading on open.  Why not wait to read until somebody
>wants to see some bytes, and just leave the buffer empty until then?
>(Apologies if this has been discussed at length already.)
>
Perhaps it has been discussed before but I appreciate having your
authoritative opinion.

I *think* that basically Benjamin wanted an in_avail called right
after the open of a non empty file to return a value != zero.
If we agree that this is a good thing (I think so) then showmanyc()
could do the trick, as suggested by Pétur.

Do you agree?

The current showmanyc() is really simple:

  template<typename _CharT, typename _Traits>
    streamsize
    basic_filebuf<_CharT, _Traits>::
    showmanyc()
    {
      streamsize __ret = -1;
      bool __testin = this->_M_mode & ios_base::in;

      if (__testin && this->is_open())
        __ret = this->_M_in_end - this->_M_in_cur;
      _M_last_overflowed = false;   
      return __ret;
    }

Dunno what can be put in it according to the standard.

What do you suggest?

Thanks,
Paolo.