RE: libstdc++/16

[Benjamin Kosnik <bkoz at cygnus dot com>]

The following reply was made to PR libstdc++/16; it has been noted by GNATS.

From: Benjamin Kosnik <bkoz@cygnus.com>
To: "Gibbons, Chad" <Chad_Gibbons@bmc.com>
Cc: libstdc++-gnats@sourceware.cygnus.com
Subject: RE: libstdc++/16
Date: Mon, 20 Mar 2000 16:16:48 -0800 (PST)

 > Yes, I agree a testcase would be extremely useful on this one. :)
 
 Yep. I'll close it in a bit if I don't have something to reproduce it
 with.
 
 > The only thing I can really say without producing a test case is to look at
 > what *can* happen:
 > 1) some code includes iostream.h, which causes the ios_base::Init __ioinit
 > object to be created in that module. That object initializes the file
 > buffers used by all the standard I/O objects.
 
 Yes. Due to c++ static init rules, objects are initialized in a first-seen
 first-initialized order. Therefore, iostream should be included before
 user-code that also has static initializers.
 
 
 > 2) because order of initialization isn't guaranteed, that code's module is
 > initialized by the linker before the creation of cout, cerr, etc.
 
 ? 
 
 look at ios_base::Init::Init in src/ios.cc: you'll see that elaborate
 steps are taken to only initialize once.
 
 > 3) when cout, cerr, etc. actually do initialize, they reset the buffers
 > created in step 1) and the streams are fubared.
 
 seems unlikely.
 
 > I'll make sure this happens on a non-Solaris platform to make sure it wasn't
 > a Solaris specific gcc/ld problem. Beyond that, though, I'm not sure I can
 > do too much. I'd probably then just file this as "something to keep an eye
 > out for." 
 
 
 I'll keep in the back of my head going forward. Thanks,
 benjamin