Re: [Patch] Change _M_overflow to call _M_convert_to_external once

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

On Wed, May 14, 2003 at 07:12:25PM +0200, Paolo Carlini wrote:
> this is my current best proposal, taking into account
> Nathan's and Benjamin's suggestions.

Looks good, Paolo.  Thank you for giving me credit on the changelog 
when you did all the work.  (I trust there will be no need for blame :)

I have just one suggestion.

> A few sparse observations:
> 1- setbuf(s(!=null), n(==1)) is simply ignored. This is allowed
> by the standard and not a big loss, probably, but still a change
> of behavior.

I would rather see setbuf(p,1) be equivalent to setbuf(0,0) than to 
simply ignore it.  However, I don't see this as a reason to hold off 
applying the patch as is, and then tweaking that later.

> 2- setbuf(0,0) leads internally to _M_buf_size == 1, that is,
> actually, zero-sized get and put areas (null pointers). Using
> this value instead of _M_buf_size == 0 simplifies _M_set_buffer.

I hoped there would be simplifications like this. 

> 3- I have renamed _M_set_determinate as _M_set_buffer, and
> removed _M_set_indeterminate which was trivially calling
> _M_set_determinate.

This makes me happy.

> 4- Two tests had to be tweaked: one relied on a BUFSIZ sized put
> area, the other on a single-char stdio_filebuf.
> 5- Before and after this patch, unbuffered basic_filebuf::_M_overflow
> and _M_underflow (a.k.a., libstdc++/9404) are still missing.
> Benjamin, which strategy do you prefer? Adding a special case to
> the current versions would now be easy.

Is there a reason to have _M_overflow() in addition to overflow()?
Is there a reason _not_ to go ahead and convert/write/flush the buffer 
even though it's not completely full?  

Nathan Myers
ncm-nospam@cantrip.org