PATCH: for Serious v3 shared library bug

[Nathan Myers]

On Thu, Jan 04, 2001 at 04:21:54PM -0600, Loren James Rittle wrote:
> In article < 20010103124909.A4504@disaster.jaj.com >,
> Phil Edwards <pedwards@disaster.jaj.com> writes:
> 
> > 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.
> 
> Off hand, I don't think so, but that answer is based on source tracing
> and single stepping only.
> 
> > 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.
> 
> I am not a language lawyer (I base all I know about this area on p651
> of TC++PL-SE), but it appears that a standard C++ program is suppose
> to do one of the following before any IO:
> 
> (1) Make no special calls.  Program gets sync'd or unsync'd IO
>     depending upon implementor preference.
> 
> (2) Call sync_with_stdio(false);
> 
> (3) Call sync_with_stdio(true);
> 
> It is unclear that calling sync_with_stdio() a second time with
> different arguments will undo any first call.  It is unclear that
> re-synching after IO operations have begun would ever be required.

Not quite.

As I recall it, for case (1), the streams must act as if synchronized.
A portable program that cares about stdio performance must do (2).  
There is never any valid reason to do (3).  The effect of (3) after 
(2) and intervening output operations is unspecified, and there is 
no reason for us to do anything to handle it.

Yes, it's an unpleasant mess.  Since for historical reasons it could 
not be cleaned up properly, it was papered over so that only the 
thing that makes sense ("just do (2) if you care") means anything.

Nathan Myers
ncm at cantrip dot org