Re: [PATCH 1/4] Revert "2017-10-04 Petr Ovtchenkov <ptr at void-ptr dot info>"

[Jonathan Wakely <jwakely at redhat dot com>]

On 16/11/17 11:39 +0000, Jonathan Wakely wrote:
> On 16/11/17 14:35 +0300, Petr Ovtchenkov wrote:
> > On Thu, 16 Nov 2017 10:56:29 +0000
> > Jonathan Wakely <jwakely@redhat.com> wrote:
> >
> > > On 10/10/17 22:55 +0300, Petr Ovtchenkov wrote:
> > > > This reverts commit 0dfbafdf338cc6899d146add5161e52efb02c067
> > > > (svn r253417).
> > >
> > > I'm not even going to bother to review patches sent without any
> > > explanation or rationale for the change.
> >
> > https://gcc.gnu.org/ml/libstdc++/2017-11/msg00044.html
> >
> > Along with "violate principles of C++ objects life cycle",
> > the side-effect is
> >
> > - Make istreambuf_iterator::_M_sbuf immutable
> > - streambuf_iterator: avoid debug-dependent behaviour
> >
> > I should underline, that "_M_sbuf = 0" when istreambuf_iterator
> > see eof, lead to cripple lifecycle of istreambuf_iterator
> > object and [almost] block usage of istreambuf_iterator
> > for entities other then immutable files.
> >
> > All tests from 24_iterators and 25_algorithms passed,
> > so I expect it conform to Standard.
> >
> > This is series of patches, not single patch because
> > I keep in mind technology aspect---easy transfer
> > to branches other then trunk.
> >
> > > I will repeat what Paolo said: changing the ABI is not acceptable.
> >
> > I will repeat special for you:
> >
> > <snip>
> > Is we really worry about frozen sizeof of instantiated template?
> > (Removed private template member).
> >
> > If yes, than
> >
> >  int_type __dummy;
> >
> > is our all.
> > </snip>
> >
> > I.e. problem can be easy resolved---i.e. ABI will not suffer, if we will
>
> What about other translation units which have inlined the old
> definition of the template, and expect to find a buffered character in
> that member?

In other words, the ABI is not just the "frozen sizeof".

> > reach some consensus on the main issue.
>
> We don't have any consensus, in fact I don't see anybody agreeing with
> you, and I've previously stated I don't want to support your use case:
> https://gcc.gnu.org/ml/libstdc++/2017-09/msg00100.html