Re: [Patch/RFC] Fix libstdc++/9533

[Nathan Myers <ncm-nospam at cantrip dot org>]

On Tue, Mar 18, 2003 at 02:48:33PM +0100, Carlo Wood wrote:
> On Tue, Mar 18, 2003 at 02:19:59PM +0100, Paolo Carlini wrote:
> > Interesting. However what we really need inside showmanyc is an estimate
> > of the _number_ of externally available chars.
> 
> Shouldn't that be 'the number of _contiguous_ characters'
> (at the beginning of the get area of the output buffer)?
> 
> Imho, that is always egptr() - gptr(),?possibly after
> first adjusting the get area pointers.  The word 'contiguous'
> implies refering to a buffer, therefore I thought it might
> be relevant.

Several people seem very confused about the purpose of showmanyc(),
and its relationship to in_avail().  

in_avail() is supposed to implemented in-line, to give a very cheap 
report on the number of characters that may be obtained without invoking 
any of the streambuf virtuals.

showmanyc() is a virtual.  It is supposed to give a lower bound
on the number of characters that can certainly be obtained without
hitting EOF.  While it should never return less than (n = egptr() - 
gptr()), on many stream types it can do better.  For filebufs attached 
to sockets or files, it can do much better, and should.  That's what 
it's *for*.  To say that it is good enough if it returns 0 is like 
saying that seekoff() might as well always report failure: it's 
conforming, why complicate matters?

Calling poll() does not suffice; the only information that syscall
can provide is that there is one or more characters to be read.
It can only support returning 1 from showmanyc (and then only when 
_CharT is char).

Any implementation that calls underflow() (even in non-blocking mode) 
is flawed: it's not supposed to be changing the state of the stream 
(i.e. the underlying filebuf), it's supposed to report status.

We have dropped the ball in our implementation of showmanyc().  Paolo
has done good work on providing an industrially useful implementation.
It may need some experimentation on various targets to get fully 
portable (and return 0 where no information can be obtained), but even 
on the most limited targets it can do no worse than what we have now.

I agree with Benjamin and P?tur that it would be better to separate 
the buffered file-descriptor- and unbuffered-FILE-based streambuf 
implementations into separate class templates.  (Certainly the code
in showmanyc() in the latter will look different.)  But that's another
project.  Probably that should be taken up when we fix basic_streambuf
itself.

Nathan Myers
ncm at cantrip dot org