This is the mail archive of the
mailing list for the libstdc++ project.
Re: Why fixing 9533 doesn't fix 7774: revealed!
- From: Nathan Myers <ncm-nospam at cantrip dot org>
- To: "libstdc++ at gcc dot gnu dot org" <libstdc++ at gcc dot gnu dot org>
- Date: Wed, 5 Mar 2003 09:57:31 -0800
- Subject: Re: Why fixing 9533 doesn't fix 7774: revealed!
- References: <3E65F7DD.firstname.lastname@example.org>
On Wed, Mar 05, 2003 at 02:13:01PM +0100, Paolo Carlini wrote:
> This is 7744 testcase: ...
> As Nathan explained, in_avail shouldn't call showmanyc but in
> fact it does. Why?
> Because after the in.peek(), egptr == gptr! Indeed, in.peek()
> calls sgetc(), which calls underflow(), which does:
> __elen = _M_file.xsgetn(reinterpret_cast<char*>(_M_in_beg),
> __ilen = __elen;
> if (0 < __ilen)
> if (__testout)
> _M_out_cur = _M_in_cur;
> __ret = traits_type::to_int_type(*_M_in_cur);
> if (__bump)
> else if (_M_buf_size == 1)
> // If we are synced with stdio, we have to unget the
> // character we just read so that the file pointer
> // doesn't move.
> There are no chances that 4 chars are put in the buffer (stdio is synced
> and _M_buf_size == 1) but we expect at least one!
> That single char _is_ in fact put into the buffer, but, since
> _M_buf_size == 1
> the char is unget and _M_set_indeterminate called, which basically reset
> all the get area pointers to _M_buf and the information on the char present
> in the buffer ends up _not_ being propagated (as egptr == gptr + 1) to
> So, a few question:
> 1- Is that _M_set_indeterminate() call really necessary for other reasons?
> 2- Is it ok to have _M_buf_size == 1 when synced with stdio?
OK, syncing with stdio is a special case. I am not surprised to see
in_avail() call showmanyc() for that case, nor to find it reporting 0.
The _M_set_indeterminate() call is necessary so that the next sgetc()
will call underflow(), and get the character out of stdin's putback
cell. It is necessary to have _M_buf_size == 1 when synced with stdio.
If the program began with "std::ios::sync_with_stdio(false);" I would hope
for different behavior. In other words, 7744 is "not a bug" without a
call to std::ios::sync_with_stdio(false). However, I find that even when
it has been called, in_avail() still returns zero on cin. That's the bug.
When that call occurs before any input, then you would like to have a
normal big buffer, so the next underflow will fill it as much as it can.
Pet?r's suggestion of a check for an empty buffer at the beginning of
underflow() fixes a grave bug.
Of course it would be much better if, when synchronizing with stdio,
we could share their buffer and putback cell, and not need _M_buf_size
equal to 1. But that's a whole other project. For now, if anybody
wants decent cin performance, they have to unsync, and then they
should be able to get it.
ncm-nospam at cantrip dot org