On Wed, 24 Jan 2018 21:34:48 +0100
François Dumont <frs.dum...@gmail.com> wrote:
> On 24/01/2018 18:53, Petr Ovtchenkov wrote:
> > On Wed, 24 Jan 2018 17:39:59 +0100
> > François Dumont <frs.dum...@gmail.com> wrote:
> >
> >> Hi
> >>
> >> I'd like to propose this new debug check. Comparing with non-eos
> >> istreambuf_iterator sounds like an obvious coding mistake.
> >>
> >> I propose it despite the stage 1 as it is just a new debug check,
> >> it doesn't impact the lib in normal mode.
> >>
> >> Tested under Linux x86_64, ok to commit ?
> >>
> >> François
> >>
> > bool
> > equal(const istreambuf_iterator& __b) const
> > - { return _M_at_eof() == __b._M_at_eof(); }
> > + {
> > + bool __this_at_eof = _M_at_eof();
> > + bool __b_at_eof = __b._M_at_eof();
> > +
> > + __glibcxx_requires_cond(__this_at_eof || __b_at_eof, _M_message(
> > + "Abnormal comparison to non-end-of-stream istreambuf_iterator"));
> > + return __this_at_eof == __b_at_eof;
> > + }
> >
> > Looks strange for me. It is legal and possible that istreambuf_iterator
> > will be in EOF state.
> >
> Sure, but consider rather the associated 3_neg.cc showing the debug
> check purpose:
>
> cistreambuf_iter it1(istrs), it2(istrs);
> it1 == it2; // No sens
>
This is what author want to say.
Neveretheless, __glibcxx_requires_cond(__this_at_eof || __b_at_eof, ...
in equal looks bogus for me.
--
- ptr
