PATCH: for Serious v3 shared library bug

[Phil Edwards]

On Tue, Jan 02, 2001 at 08:19:19PM -0600, Loren James Rittle wrote:
> 
> OK, that would be: http://gcc.gnu.org/ml/libstdc++/2000-12/msg00264.html
> 
> Did the eggnog-induced vision provide much insight? ;-)

I think so, but it was on a flight with heavy turbulance.  Not much thinking
got done after the first hundred miles.  :-)


> > 1)  How does ios_base::Init::Init() get away with calling __old->~streambuf()
> > to dispose of buffers, where doing the same thing during sync_with_stdio()
> > closes the descriptors?
> 
> There is a difference between a streambuf and a filebuf.  Just by
> tracing the source, it is clear to see that ~filebuf() closes the
> descriptor.  A streambuf holds no descriptor, thus there is nothing to
> close.

Right, but shouldn't a sequence like

    streambuf*  __old;
    __ioinit._M_cout = new filebuf(1, "stdout", ios_base::out);
    __old = cout.rdbuf(__ioinit._M_cout);
    __old->~streambuf();

not call ~filebuf()?  This is one of the variations I tried in
sync_with_stdio.

This may be a case where I'm being dense; the semantics of explicit dtor
calls aren't something I'm an expert on.  And I don't yet have a working
PDF reader to consult the standard.


I'll try your patch as soon as I get everything else back together.  I think
I have a solution for the non-dup'able systems, but don't hold your breath.

And I'm not certain at all about what's supposed to be the state of the
world after

    sync_with_stdio(false);
    sync_with_stdio(true);

Re-synching is just going to be a barrel of fun.


Phil

-- 
pedwards at disaster dot jaj dot com  |  pme at sources dot redhat dot com
devphil at several other less interesting addresses in various dot domains
The gods do not protect fools.  Fools are protected by more capable fools.