Re: [Patch] Clean up sbumpc, move back _M_buf_size, do not special case unbuffered _M_underflow...

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

On Mon, Jun 09, 2003 at 04:40:58PM -0500, Benjamin Kosnik wrote:
> 
> >The other case, where it's already open but no I/O has 
> >happened yet, is a problem.  We do nothing, then, but the standard says 
> >it *must* become unbuffered.  
> 
> If opening is considered an io operation, then the behavior, as it
> stands, is correct.  This is what v2/v3/icc do, and seems reasonable
> given the alternative you outline....

If you call a tail a leg, how many legs does a dog have?  (Four.)

Opening is not in fact an I/O operation.  Opening is preparation to 
allow an I/O operation.  Otherwise, does "I/O operation" have any 
meaning?  Maybe construction is an I/O operation.  The purpose of
the restriction on I/O was to avoid saying what happens to any text
in the buffer, not to give us every excuse to make things hard on 
users.

We can support reasonable behavior under a much wider variety of 
circumstances than we do, at no extra cost.  The present behavior 
silently ignores the user request far more often than could rationally 
be called reasonable.

> >The fact is, we aren't required to care whether I/O has been done.  
> 
> Again, see:
> 
> 27.8.1.4 - Overridden virtual functions

Of course I have read it, plenty of times.  (Have you?)  It defines 
what must happen if I/O has not been done, and leaves all other 
conditions implementation-defined.  That _allows_ us to do the same 
thing for all cases, as long as what we do is what the standard 
requires for the case of no I/O.  But I did not propose that; I was 
simply making a factual statement about the standard requirements.
If you disagree with that statement, you have not read carefully.

But we don't even comply with what it does require.

> If you think there is a bug in the standard, please file a DR...

Please don't try to change the subject.  

> >If there's something in a buffer, we are free to discard it.
> 
> .... or else this situation is entered. I disagree with your
> interpretation here.

Which part of "implementation-defined" do you disagree with?
If I/O has been performed, we are allowed by the standard to do 
anything that we can describe (up to impregnating our respective 
sisters-in-law) as long as it doesn't contradict other standard 
requirements.

But do we have obligations to be more or less backward compatible,
and to behave reasonably.  That doesn't mean we have to do nothing 
anywhere v2 or v3 ever did; a call to setbuf that has no effect is 
a latent bug, and we have no obligation to preserve bugs.  The code 
I proposed behaves reasonably in many more cases than does the 
present code.

A reasoned response would have been to point out a case where, 
in fact, it would not behave reasonably, and to propose what you
think it should do instead in that case.

Nathan Myers
ncm-nospam@cantrip.org