This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Patch] Fix libstdc++/9533


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]