Re: libstdc++/2: valarray assignment operators don't resize

[Benjamin Kosnik <bkoz@cygnus.com>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 70199 bytes --]

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

From: Benjamin Kosnik <bkoz@cygnus.com>
To: rob@geonexuscorp.com
Cc: libstdc++-gnats@sourceware.cygnus.com, gdr@sourceware.cygnus.com
Subject: Re: libstdc++/2: valarray assignment operators don't resize
Date: Tue, 24 Aug 1999 11:00:14 -0700 (PDT)

 > >Number:         2
 > >Category:       libstdc++
 > >Synopsis:       valarray assignment operators don't resize
 > >Confidential:   no
 > >Severity:       serious
 > >Priority:       high
 > >Responsible:    unassigned
 > >State:          open
 > >Class:          sw-bug
 > >Submitter-Id:   net
 > >Arrival-Date:   Mon Aug 23 20:47:00 PDT 1999
 > >Closed-Date:
 > >Last-Modified:
 > >Originator:     Robert Campbell
 > >Release:        2.90.6
 > >Organization:
 > >Environment:
 > RedHat Linux 5.2 with glibc libraries	
 > >Description:
 > The various valarray<T>::operator=(...) methods do not
 > resize the object as it should.  This results in core dumps if
 > the target objects allocated memory is smaller than the sources.
 
 thanks! this looks like a very well-formulated bug report. I appreciate
 you taking the time to do this.
 
 Gaby's the person for the numerics and libstdc+-v3, and valarray is
 entirely under his domain. I'll pass it off to him after he gets back from
 Africa, and expect he'll get in touch with you shortly afterwards.
 
 thanks,
 benjamin
 
>From bmosher@csc.com Wed Aug 25 11:47:00 1999
From: bmosher@csc.com
To: libstdc++-gnats@sourceware.cygnus.com
Subject: libstdc++/3: Segmentation Faults in substr() and string()
Date: Wed, 25 Aug 1999 11:47:00 -0000
Message-id: <19990825183951.9939.qmail@egcs.cygnus.com>
X-SW-Source: 1999-q3/msg00001.html
Content-length: 2730

>Number:         3
>Category:       libstdc++
>Synopsis:       Segmentation Faults in substr() and string()
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Aug 25 11:47:00 PDT 1999
>Closed-Date:
>Last-Modified:
>Originator:     Bob Mosher, Computer Sciences Corporation (210)733-4825
>Release:        2.8.1, 2.8.1.1
>Organization:
>Environment:
SPARC Ultra 60, Solaris 2.6, gcc 2.8.1
>Description:
Example One ( segfault in substr() ):
  This segfault happens after correctly handling five other
  substr() calls in three separate source code modules.
  I've tried:
    - string s = current_line(21,4);
    - string s = current_line(21);
    - string s(current_line,21,4);
    - string s(current_line,21);
    - removing and reinstalling the compiler and associated libraries;
    - replacing the RAM;
  Nothing helps.

  Source code snippet:
  ulong
  rta:: ParseConnectionNumber(string current_line )
  {
    string s = current_line;
    unsigned long connection_number = 0;

    string cnumber = s.substr(21);  // segfault here
  
    return connection_number;
  }

  Error message reported by gdb:
  Program received signal SIGSEGV, Segmentation fault.
  0x1bbe8 in basic_string<char, string_char_traits<char>, __default_alloc_template<false, 0> >::replace (this=0xefffefc8, 
pos=0, n1=0, s=0xa6d25 " 157", n2=4) at stl/stl_alloc.h:407
stl/stl_alloc.h:407: No such file or directory.

stl_alloc.h is present and I had "-I/usr/local/include/g++"
in the makefile.



Example Two ( segfault in string() ):
  If I comment out the offending line in Example One, Example Two appears
  in a different code module.  The while() loop correctly processes 
  eleven lines of text before segfaulting on the twelfth, which is a 
  blank line. Of the eleven lines correctly processed, two were blank.
  You'll note the error messages are nearly identical.

  Source code snippet:
  Parse44():
    int i = 24;
    while(!found)
      {
        fin.getline( buffer, LINELENGTH, '\n' );
        cout << "Parse44() buffer[" << i << "] = " << buffer << endl;
        str = string(buffer);   // segfault here
        cout << "Parse44() str        = " << str << endl;
      }

  Error message reported by gdb:
  Program received signal SIGSEGV, Segmentation fault.
0x1bb58 in basic_string<char, string_char_traits<char>, __default_alloc_template<false, 0> >::replace (this=0xeffff050, 
pos=0, n1=0, s=0xeffff170 "", n2=0) at stl/stl_alloc.h:407
stl/stl_alloc.h:407: No such file or directory.

>How-To-Repeat:
I wish I could keep it from repeating.
>Fix:
Not a clue.
>Release-Note:
>Audit-Trail:
>Unformatted:
>From bkoz@cygnus.com Wed Aug 25 13:07:00 1999
From: Benjamin Kosnik <bkoz@cygnus.com>
To: nobody@sourceware.cygnus.com
Cc: libstdc++-prs@sourceware.cygnus.com
Subject: Re: libstdc++/3: Segmentation Faults in substr() and string()
Date: Wed, 25 Aug 1999 13:07:00 -0000
Message-id: <19990825200704.25252.qmail@egcs.cygnus.com>
X-SW-Source: 1999-q3/msg00002.html
Content-length: 2148

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

From: Benjamin Kosnik <bkoz@cygnus.com>
To: bmosher@csc.com
Cc: libstdc++-gnats@sourceware.cygnus.com,
        GNATS Management <gnats-admin@sourceware.cygnus.com>,
        nobody@sourceware.cygnus.com, libstdc++-prs@sourceware.cygnus.com
Subject: Re: libstdc++/3: Segmentation Faults in substr() and string()
Date: Wed, 25 Aug 1999 12:59:55 -0700 (PDT)

 Bob. 
 
 This database is for the libstdc++-v3 project, not the libstdc++-v2 that
 comes with gcc-2.8.1.
 
 I'd test this for you with v-3, but cannot as your examples are not
 self-contained. I need something I can just compile and debug, not bits of
 your code with dangling class defintions and method calls--
 
 > 
 >   Source code snippet:
 >   ulong
 >   rta:: ParseConnectionNumber(string current_line )
 >   {
 >     string s = current_line;
 >     unsigned long connection_number = 0;
 > 
 >     string cnumber = s.substr(21);  // segfault here
 >   
 >     return connection_number;
 >   }
 > 
 
 what I'd need, is a minimal example that reproduces this. I cannot compile
 this as I don't know the defs for the class rta, or how this method is
 called. Kay?
 
 
 >   If I comment out the offending line in Example One, Example Two appears
 >   in a different code module.  The while() loop correctly processes 
 >   eleven lines of text before segfaulting on the twelfth, which is a 
 >   blank line. Of the eleven lines correctly processed, two were blank.
 >   You'll note the error messages are nearly identical.
 > 
 >   Source code snippet:
 >   Parse44():
 >     int i = 24;
 >     while(!found)
 >       {
 >         fin.getline( buffer, LINELENGTH, '\n' );
 >         cout << "Parse44() buffer[" << i << "] = " << buffer << endl;
 >         str = string(buffer);   // segfault here
 >         cout << "Parse44() str        = " << str << endl;
 >       }
 > 
 
 Again, I need more info.
 
 
 That being said, I can say that making the string class more robust was
 one of the goals of v-3, and what is currently shipping actually passes
 commercial validation suites for chapter 21.
 
 -benjamin
 
>From jihem@math.ucdavis.edu Wed Aug 25 13:27:00 1999
From: jihem@math.ucdavis.edu
To: libstdc++-gnats@sourceware.cygnus.com
Cc: gdr@sourceware.cygnus.com
Subject: libstdc++/4: Floats in std_cmath.h
Date: Wed, 25 Aug 1999 13:27:00 -0000
Message-id: <19990825202459.26886.qmail@egcs.cygnus.com>
X-SW-Source: 1999-q3/msg00003.html
Content-length: 951

>Number:         4
>Category:       libstdc++
>Synopsis:       Floats in std_cmath.h
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Aug 25 13:27:09 PDT 1999
>Closed-Date:
>Last-Modified:
>Originator:     Jean-Marie Aubry
>Release:        gcc version 2.95.1 and libstdc++-2.90.6
>Organization:
>Environment:
i686-pc-linux-gnu
>Description:
Hello everybody,

With gcc version 2.95.1 and libstdc++-2.90.6 on an i686-pc-linux-gnu,
the following code:

#include <bits/std_cmath.h>

int main() {

    sin(static_cast<float>(0));

    return 0;

}

compiles but the executable generates a Segmentation Fault. This happens
with any math function in place of the sin. With double instead of float
it runs fine. What's going on there ?

--

JiheM
>How-To-Repeat:
see above
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:
>From hob@scali.com Thu Aug 26 03:37:00 1999
From: hob@scali.com
To: libstdc++-gnats@sourceware.cygnus.com
Cc: rws@scali.no
Subject: libstdc++/5: libstdc++ is not transparent to -malign-double egcs switch
Date: Thu, 26 Aug 1999 03:37:00 -0000
Message-id: <19990826102803.20536.qmail@egcs.cygnus.com>
X-SW-Source: 1999-q3/msg00004.html
Content-length: 965

>Number:         5
>Category:       libstdc++
>Synopsis:       libstdc++ is not transparent to -malign-double egcs switch
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Aug 26 03:37:04 PDT 1999
>Closed-Date:
>Last-Modified:
>Originator:     HÃ¥kon O. Bugge
>Release:        2.9.0
>Organization:
>Environment:
RH 6.0, egcs 1.1.2, x86
>Description:
Applications using libio.h (f. eks.) cannot be 
compiled with "-malign-double" egcs switch. If it does, the
size of struct _IO_FILE changes, and the application
crashes.
>How-To-Repeat:
Example:
----------
#include <libio.h>
#include <stdio.h>

int main() {
 
 printf("sizeof(struct _IO_FILE) = %3d\n", sizeof(struct _IO_FILE));
  return 0;
}
-----------

The program above yields different result
compiled with -m{no-}align-double
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:
>From clasen@mathematik.uni-freiburg.de Mon Aug 30 12:27:00 1999
From: clasen@mathematik.uni-freiburg.de
To: libstdc++-gnats@sourceware.cygnus.com
Subject: libstdc++/6: SIGILL in __builtin_new 
Date: Mon, 30 Aug 1999 12:27:00 -0000
Message-id: <19990830191725.7286.qmail@egcs.cygnus.com>
X-SW-Source: 1999-q3/msg00005.html
Content-length: 2538

>Number:         6
>Category:       libstdc++
>Synopsis:       SIGILL in __builtin_new
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Aug 30 12:27:02 PDT 1999
>Closed-Date:
>Last-Modified:
>Originator:     clasen@mathematik.uni-freiburg.de
>Release:        2.95
>Organization:
>Environment:
RedHat 6.0/i386 with gcc-2.95-4.i386.rpm and libstdc++-2.95-4.i386.rpm
from contrib.redhat.com installed. 
>Description:
I get a SIGILL from any C++ program that uses
new[] on a template class. Maybe the libstdc++-rpm
is just broken, I would have tried to verify this
by reinstalling from source, but there is no src.rpm
on contrib.redhat.com...
>How-To-Repeat:
Here is a little example program that exhibits the problem:

//START
#include <stdio.h>

template<class T>
class test {
 public:
  test() : x_(0) { printf("test::test()\n"); }
  test(T x) : x_(x) { printf("test::test(%d)\n", int(x)); }
  T value() { return x_; }
 private:
  T x_;
};
//END


Here is what I get from compiling and running it:


bash$ make test
g++     test.cc   -o test
bash$ ./test
Illegal instruction (core dumped)
bash$ gdb ./test core
GNU gdb 4.17.0.11 with Linux support
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...
Core was generated by `./test'.
Program terminated with signal 4, Ungültiger Maschinenbefehl.
Reading symbols from /usr/lib/libstdc++-libc6.1-2.so.3...done.
Reading symbols from /lib/libm.so.6...done.
Reading symbols from /lib/libc.so.6...done.
Reading symbols from /lib/ld-linux.so.2...done.
#0  0x4004f240 in __builtin_new (sz=20)
(gdb) bt
#0  0x4004f240 in __builtin_new (sz=20)
#1  0x4004f443 in __builtin_vec_new (sz=20)
#2  0x804866a in main ()
#3  0x40096cb3 in __libc_start_main (main=0x8048650 <main>, argc=1, 
    argv=0xbffff884, init=0x80484ac <_init>, fini=0x8048788 <_fini>, 
    rtld_fini=0x4000a350 <_dl_fini>, stack_end=0xbffff87c)
    at ../sysdeps/generic/libc-start.c:78
Current language:  auto; currently c++
(gdb) 



int main (int argc, char **argv)
{
  test<int> *u = 0;
  u = new test<int>[5];
  return 0;
}

>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:
>From bkoz@cygnus.com Tue Aug 31 17:50:00 1999
From: bkoz@cygnus.com
To: bkoz@cygnus.com, bmosher@csc.com, libstdc++-prs@sourceware.cygnus.com, nobody@sourceware.cygnus.com
Subject: Re: libstdc++/3
Date: Tue, 31 Aug 1999 17:50:00 -0000
Message-id: <19990901005047.15910.qmail@egcs.cygnus.com>
X-SW-Source: 1999-q3/msg00006.html
Content-length: 483

Synopsis: Segmentation Faults in substr() and string()

Responsible-Changed-From-To: unassigned->bkoz
Responsible-Changed-By: bkoz
Responsible-Changed-When: Tue Aug 31 17:50:47 1999
Responsible-Changed-Why:
    taking responsibility for this. . .
State-Changed-From-To: open->feedback
State-Changed-By: bkoz
State-Changed-When: Tue Aug 31 17:50:47 1999
State-Changed-Why:
    awaiting a response. . 

http://sourceware.cygnus.com/cgi-bin/gnatsweb.pl?cmd=view&database=libstdc++&pr=3
>From bkoz@cygnus.com Tue Aug 31 18:00:00 1999
From: bkoz@cygnus.com
To: bkoz@cygnus.com, clasen@mathematik.uni-freiburg.de, libstdc++-prs@sourceware.cygnus.com, nobody@sourceware.cygnus.com
Subject: Re: libstdc++/6
Date: Tue, 31 Aug 1999 18:00:00 -0000
Message-id: <19990901010026.17453.qmail@egcs.cygnus.com>
X-SW-Source: 1999-q3/msg00007.html
Content-length: 742

Synopsis: SIGILL in __builtin_new

Responsible-Changed-From-To: unassigned->bkoz
Responsible-Changed-By: bkoz
Responsible-Changed-When: Tue Aug 31 18:00:26 1999
Responsible-Changed-Why:
    taking it. . .
State-Changed-From-To: open->closed
State-Changed-By: bkoz
State-Changed-When: Tue Aug 31 18:00:26 1999
State-Changed-Why:
    1) not with v-3, with the 2.95 release.
    2) can't be reproduced with any release. I've tried:
    a) RH6 g++/libstdc++ (based on egcs1.1.2)
    b) egcs CVS
    c) egcs-2.95 hosted on RH6
    
    looks like an installation error. Get the sources from egcs.cygnus.com for the 2.95 release and try building it yourself. . . .

http://sourceware.cygnus.com/cgi-bin/gnatsweb.pl?cmd=view&database=libstdc++&pr=6
>From bkoz@cygnus.com Tue Aug 31 18:02:00 1999
From: bkoz@cygnus.com
To: bkoz@cygnus.com, jihem@math.ucdavis.edu, libstdc++-prs@sourceware.cygnus.com, nobody@sourceware.cygnus.com
Subject: Re: libstdc++/4
Date: Tue, 31 Aug 1999 18:02:00 -0000
Message-id: <19990901010229.18597.qmail@egcs.cygnus.com>
X-SW-Source: 1999-q3/msg00008.html
Content-length: 957

Synopsis: Floats in std_cmath.h

Responsible-Changed-From-To: unassigned->bkoz
Responsible-Changed-By: bkoz
Responsible-Changed-When: Tue Aug 31 18:02:29 1999
Responsible-Changed-Why:
    looking at this whilest gaby is in africa
State-Changed-From-To: open->feedback
State-Changed-By: bkoz
State-Changed-When: Tue Aug 31 18:02:29 1999
State-Changed-Why:
    This fixes it. It's messy, but the autoconf wrangling continues. . .
    1999-08-25  Benjamin Kosnik  <bkoz@cygnus.com>
    
    	* acconfig.h: Add absf, cosf.
    	* configure.in (use_builtin_sinf): Same.
    	* configure: Regenerate.
    	* bits/std_cmath.h: Add mess of defines.
    	* testsuite/26_numerics/modf_float.cc: Change to
    	* testsuite/26_numerics/c_math.cc: This.
    	
    	* src/locale.cc: Change.
    	* bits/locale_facets.h: Fix.
    	* testsuite/22_locale/ctype.cc: Add temporary tests.
    

http://sourceware.cygnus.com/cgi-bin/gnatsweb.pl?cmd=view&database=libstdc++&pr=4
>From bkoz@cygnus.com Tue Aug 31 18:10:00 1999
From: bkoz@cygnus.com
To: bkoz@cygnus.com, hob@scali.com, libstdc++-prs@sourceware.cygnus.com, nobody@sourceware.cygnus.com
Subject: Re: libstdc++/5
Date: Tue, 31 Aug 1999 18:10:00 -0000
Message-id: <19990901011030.21592.qmail@egcs.cygnus.com>
X-SW-Source: 1999-q3/msg00009.html
Content-length: 1146

Synopsis: libstdc++ is not transparent to -malign-double egcs switch

Responsible-Changed-From-To: unassigned->bkoz
Responsible-Changed-By: bkoz
Responsible-Changed-When: Tue Aug 31 18:10:29 1999
Responsible-Changed-Why:
    taking it. . .
State-Changed-From-To: open->feedback
State-Changed-By: bkoz
State-Changed-When: Tue Aug 31 18:10:29 1999
State-Changed-Why:
    Hmm. I'm able to compile this:
    #include <libio.h>
    #include <stdio.h>
    #include <iostream>
    
    int main() {
      
      printf("sizeof(struct _IO_FILE) = %3d\n", sizeof(struct _IO_FILE));
    
      cout<<"this crashes then"<<endl;
      return 0;
    
    }
    
    
    like so:
    
    g++ -malign-double list08.cc
    
    and get:
    
    %a.out
    sizeof(struct _IO_FILE) = 152
    this crashes then
    
    
    I'm not quite sure I see your problem. If you are doing offsets of the _IO_FILE struct, it won't work, but then again, as this is reserved for the implementation, you're taking your life in your own hands with this approach. . ..
    
    -benjamin
    

http://sourceware.cygnus.com/cgi-bin/gnatsweb.pl?cmd=view&database=libstdc++&pr=5
>From tphillips@iee.org Fri Sep 03 04:07:00 1999
From: tphillips@iee.org
To: libstdc++-gnats@sourceware.cygnus.com
Subject: libstdc++/7: Build fails on Intel/Solaris 2.7
Date: Fri, 03 Sep 1999 04:07:00 -0000
Message-id: <19990903105847.12253.qmail@egcs.cygnus.com>
X-SW-Source: 1999-q3/msg00010.html
Content-length: 2285

>Number:         7
>Category:       libstdc++
>Synopsis:       Build fails on Intel/Solaris 2.7
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Sep 03 04:07:01 PDT 1999
>Closed-Date:
>Last-Modified:
>Originator:     tphillips@iee.org
>Release:        2.90.6
>Organization:
>Environment:
Intel Solaris dual processor with Solaris 2.7
GNU gcc version 2.95
gmake 3.77
>Description:
The build of the libstdc++ library fails and recommends reporting a bug.  The following is the tail of the make output:

In file included from /usr/local/lib/gcc-lib/i386-pc-solaris2.7/2.95/include/limits.h:117,
                 from /usr/local/lib/gcc-lib/i386-pc-solaris2.7/2.95/include/syslimits.h:7,
                 from /usr/local/lib/gcc-lib/i386-pc-solaris2.7/2.95/include/limits.h:11,
                 from ../bits/std_climits.h:38,
                 from ../bits/localefwd.h:38,
                 from ../bits/std_locale.h:37,
                 from locale-inst.cc:40:
/usr/include/limits.h:204: warning: `DBL_MAX' redefined
/usr/local/lib/gcc-lib/i386-pc-solaris2.7/2.95/include/float.h:63: warning: this is the location of the previous definition
/usr/include/limits.h:206: warning: `DBL_MIN' redefined
/usr/local/lib/gcc-lib/i386-pc-solaris2.7/2.95/include/float.h:54: warning: this is the location of the previous definition
/usr/include/limits.h:209: warning: `FLT_MAX' redefined
/usr/local/lib/gcc-lib/i386-pc-solaris2.7/2.95/include/float.h:35: warning: this is the location of the previous definition
/usr/include/limits.h:210: warning: `FLT_MIN' redefined
/usr/local/lib/gcc-lib/i386-pc-solaris2.7/2.95/include/float.h:26: warning: this is the location of the previous definition
../bits/string.tcc:54: Internal compiler error in `dwarfout_finish', at dwarfout.c:6098
Please submit a full bug report.
See <URL: http://egcs.cygnus.com/faq.html#bugreport > for instructions.
make[1]: *** [locale-inst.lo] Error 1
make[1]: Leaving directory `/usr5/gnu/libstdc++-2.90.6/src'
make: *** [all-recursive] Error 1
*** Error code 2
make: Fatal error: Command failed for target `all-recursive-am'
>How-To-Repeat:

>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:
>From dek@cgl.ucsf.edu Tue Sep 07 09:57:00 1999
From: dek@cgl.ucsf.edu
To: libstdc++-gnats@sourceware.cygnus.com
Subject: libstdc++/8: writing large strings to an ofstream causes stream to go bad
Date: Tue, 07 Sep 1999 09:57:00 -0000
Message-id: <19990907165205.15459.qmail@egcs.cygnus.com>
X-SW-Source: 1999-q3/msg00011.html
Content-length: 1275

>Number:         8
>Category:       libstdc++
>Synopsis:       writing large strings to an ofstream causes stream to go bad
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Sep 07 09:57:01 PDT 1999
>Closed-Date:
>Last-Modified:
>Originator:     dek@cgl.ucsf.edu
>Release:        libstdc++ 2.90 current CVS (as of Sept 6)
>Organization:
>Environment:
Mandrake Linux 6.0 w/ gcc-2.95
>Description:
Writing large (>5000 bytes) strings to an ofstream
causes the ofstream to go "bad".
>How-To-Repeat:
#include <string>
#include <fstream>

const int i_max=250;

void test(int size)
{
  int i;

  string filename;
  std::ofstream f("out.log");

  std::cout << "Testing with size " << size << std::endl;
  std::cout << "State of f:" << f.good() << std::endl; 
  string x(size, 'c');

  f << x << endl;
  std::cout << "State of f:" << f.good() << std::endl; 
  if (!f.good()) exit(1);

  f << x << endl;
  std::cout << "State of f:" << f.good() << std::endl; 
  if (!f.good()) exit(1);

  f.close();
  return;
}

int main()
{

  test(1000); 
  test(10000);
}
>Fix:
? Perhaps an internal buffer is only 4k.
>Release-Note:
>Audit-Trail:
>Unformatted:
>From mjollnir@citysearch.com Thu Sep 09 21:07:00 1999
From: mjollnir@citysearch.com
To: libstdc++-gnats@sourceware.cygnus.com
Subject: libstdc++/9: libstdc++.2.9.0.6 does NOT build on Solaris2.6 with gcc2.95 or native CC
Date: Thu, 09 Sep 1999 21:07:00 -0000
Message-id: <19990910040205.21252.qmail@egcs.cygnus.com>
X-SW-Source: 1999-q3/msg00012.html
Content-length: 1638

>Number:         9
>Category:       libstdc++
>Synopsis:       libstdc++.2.9.0.6 does NOT build on Solaris2.6 with gcc2.95 or native CC
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Sep 09 21:07:00 PDT 1999
>Closed-Date:
>Last-Modified:
>Originator:     mjollnir@citysearch.com
>Release:        libstdc++-2.9.0.6
>Organization:
>Environment:
Solaris-2.6
E-250
Compilers tried: gcc-2.8.1, gcc-2.95.1, SUNWspro/bin/cc
>Description:
bash-2.02# make
make  all-recursive
Making all in math
Making all in string
Making all in libio
Making all in src
make: Fatal error in reader: Makefile, line 484: Extra `:', `::', or `:=' on dependency line
Current working directory /opt/libstdc++-2.90.6/src
*** Error code 1
make: Fatal error: Command failed for target `all-recursive'
Current working directory /opt/libstdc++-2.90.6
*** Error code 1
make: Fatal error: Command failed for target `all-recursive-am'
bash-2.02# cd src
bash-2.02# vi Makefile


line 484 is next one but last in this excerpt:

myinstallheaders: $(headers:%=$(myincludepfx)%)
        @for i in $(std_headers); do \
          echo "$(INSTALL_DATA) $(top_srcdir)/std/$$i $(myincludepfx)"; \
                $(INSTALL_DATA) $(top_srcdir)/std/$$i $(myincludepfx); \
        done
        $(INSTALL_DATA) $(top_builddir)/bits/std_limits.h $(myincludepfx)/bits
        $(INSTALL_DATA) $(top_builddir)/bits/c++config.h $(myincludepfx)/bits
>How-To-Repeat:
Run configure
Run make
>Fix:
?
Looks OK to my eyes
>Release-Note:
>Audit-Trail:
>Unformatted:
>From dosreisATcmla.ens-cachan.fr Tue Sep 14 06:17:00 1999
From: Gabriel Dos Reis <dosreis AT cmla.ens-cachan.fr>
To: nobody AT sourceware.cygnus.com
Cc: libstdc++-prs AT sourceware.cygnus.com
Subject: Re: libstdc++/2: valarray assignment operators don't resize
Date: Tue, 14 Sep 1999 06:17:00 -0000
Message-id: <19990914131700.3214.qmail@egcs.cygnus.com>
X-SW-Source: 1999-q3/msg00013.html
Content-length: 1699

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

From: Gabriel Dos Reis <dosreis@cmla.ens-cachan.fr>
To: Benjamin Kosnik <bkoz@cygnus.com>
Cc: rob@geonexuscorp.com, libstdc++-gnats@sourceware.cygnus.com,
        gdr@sourceware.cygnus.com
Subject: Re: libstdc++/2: valarray assignment operators don't resize
Date: 14 Sep 1999 15:07:53 +0200

 Benjamin Kosnik <bkoz@cygnus.com> writes:
 
 | > >Number:         2
 | > >Category:       libstdc++
 | > >Synopsis:       valarray assignment operators don't resize
 | > >Confidential:   no
 | > >Severity:       serious
 | > >Priority:       high
 | > >Responsible:    unassigned
 | > >State:          open
 | > >Class:          sw-bug
 | > >Submitter-Id:   net
 | > >Arrival-Date:   Mon Aug 23 20:47:00 PDT 1999
 | > >Closed-Date:
 | > >Last-Modified:
 | > >Originator:     Robert Campbell
 | > >Release:        2.90.6
 | > >Organization:
 | > >Environment:
 | > RedHat Linux 5.2 with glibc libraries	
 | > >Description:
 | > The various valarray<T>::operator=(...) methods do not
 | > resize the object as it should.  
 
 They don't have to.
 
   26.3.2.2 valarray assignment
   1  ... The resulting behaviour is undefined if the length of the
      argument array is not equal to the length of the *this array.
 
 Furthermore:
   
   26.3.2.6/3 If the array and the argument array do not have the same
   length, the behavior is undefined.
 
 
 I deliberately decided not to check array's length because valarrays
 are basic building blocks and valarray operations are intended to be
 primitive ones.  It is the user's responsability to check bound, in the
 same way he has to be cautious when deferencing pointer.
 
 -- Gaby
>From Roman.Kagan@itep.ru Sat Sep 18 10:47:00 1999
From: Roman.Kagan@itep.ru
To: libstdc++-gnats@sourceware.cygnus.com
Subject: libstdc++/10: _Expr<>.sum() in bits/valarray_meta.h doesn't compile
Date: Sat, 18 Sep 1999 10:47:00 -0000
Message-id: <19990918174329.25572.qmail@egcs.cygnus.com>
X-SW-Source: 1999-q3/msg00014.html
Content-length: 1972

>Number:         10
>Category:       libstdc++
>Synopsis:       _Expr<>.sum() in bits/valarray_meta.h doesn't compile
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Sep 18 10:47:01 PDT 1999
>Closed-Date:
>Last-Modified:
>Originator:     Roman Kagan
>Release:        2.90.6 and 2.10.0 (bundled with gcc-2.95.1)
>Organization:
>Environment:
i686 linux-2.2.10 glibc-2.1.1 gcc-2.95.1
>Description:
Template class _Expr in bits/valarray_meta.h has method sum(),
which starts with line

        _Tp __s(_Tp());

It is (incorrectly?) interpreted by g++ as a function declaration
rather than an object definition with initialization (BTW so do
other compilers - KCC, IBM xlC, HP aCC).  Such behavior is also
mentioned as a known bug of gcc (see http://gcc.gnu.org/bugs.html ,
section "Parse errors for "simple" code").
>How-To-Repeat:
#include <valarray>
main()
{
  std::valarray<float> a(3);
  (a * a).sum();
}
>Fix:
--- libstdc++-2.90.6/bits/valarray_meta.h~      Thu Jun 10 23:05:29 1999
+++ libstdc++-2.90.6/bits/valarray_meta.h       Sat Sep 18 20:37:27 1999
@@ -716,14 +716,14 @@
     inline size_t
     _Expr<_Clos,_Tp>::size () const  { return _M_closure.size (); }
     
-    // XXX: replace this with a more robust summation algorithm.
     template<class _Clos, typename _Tp>
     inline _Tp
     _Expr<_Clos,_Tp>::sum () const
     {
-        _Tp __s(_Tp());
-        size_t __n (_M_closure.size ());
-        for (size_t __i=0; __i<__n; ++__i) __s += _M_closure[__i];
+        size_t __i (_M_closure.size ());
+        if(!__i) return _Tp();
+        _Tp __s(_M_closure[--__i]);
+        while(__i) __s += _M_closure[--__i];
         return __s;
     }
     
It also reduces the number of temporaries and constructor calls,
which might be worth doing to the rest of the valarray files.
>Release-Note:
>Audit-Trail:
>Unformatted:
>From bkoz@cygnus.com Thu Sep 23 02:05:00 1999
From: bkoz@cygnus.com
To: bkoz@cygnus.com, dek@cgl.ucsf.edu, libstdc++-prs@sourceware.cygnus.com, nobody@sourceware.cygnus.com
Subject: Re: libstdc++/8
Date: Thu, 23 Sep 1999 02:05:00 -0000
Message-id: <19990923090527.19874.qmail@egcs.cygnus.com>
X-SW-Source: 1999-q3/msg00015.html
Content-length: 643

Synopsis: writing large strings to an ofstream causes stream to go bad

Responsible-Changed-From-To: unassigned->bkoz
Responsible-Changed-By: bkoz
Responsible-Changed-When: Thu Sep 23 02:05:27 1999
Responsible-Changed-Why:
    io/buffers, mine
State-Changed-From-To: open->feedback
State-Changed-By: bkoz
State-Changed-When: Thu Sep 23 02:05:27 1999
State-Changed-Why:
    Looks to be fixed with stringstreams and fstreams as of this patch:
    1999-09-23  Benjamin Kosnik  <bkoz@milou.cygnus.com>
    
    	* bits/streambuf.tcc: Yeah. Fix this for real.
    

http://sourceware.cygnus.com/cgi-bin/gnatsweb.pl?cmd=view&database=libstdc++&pr=8
>From bkoz@cygnus.com Thu Sep 23 02:07:00 1999
From: bkoz@cygnus.com
To: bkoz@cygnus.com, libstdc++-prs@sourceware.cygnus.com, mjollnir@citysearch.com, nobody@sourceware.cygnus.com
Subject: Re: libstdc++/9
Date: Thu, 23 Sep 1999 02:07:00 -0000
Message-id: <19990923090703.19995.qmail@egcs.cygnus.com>
X-SW-Source: 1999-q3/msg00016.html
Content-length: 503

Synopsis: libstdc++.2.9.0.6 does NOT build on Solaris2.6 with gcc2.95 or native CC

Responsible-Changed-From-To: unassigned->bkoz
Responsible-Changed-By: bkoz
Responsible-Changed-When: Thu Sep 23 02:07:03 1999
Responsible-Changed-Why:
    I'm dealing with this
State-Changed-From-To: open->feedback
State-Changed-By: bkoz
State-Changed-When: Thu Sep 23 02:07:03 1999
State-Changed-Why:
    waiting for feedback or state

http://sourceware.cygnus.com/cgi-bin/gnatsweb.pl?cmd=view&database=libstdc++&pr=9
>From aschmidt@lynet.de Thu Oct 14 04:27:00 1999
From: aschmidt@lynet.de
To: libstdc++-gnats@sourceware.cygnus.com
Subject: libstdc++/11: invalid type for default argument
Date: Thu, 14 Oct 1999 04:27:00 -0000
Message-id: <19991014112640.16051.qmail@sourceware.cygnus.com>
X-SW-Source: 1999-q4/msg00000.html
Content-length: 1181

>Number:         11
>Category:       libstdc++
>Synopsis:       invalid type for default argument
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Oct 14 04:27:00 PDT 1999
>Closed-Date:
>Last-Modified:
>Originator:     aschmidt@lynet.de
>Release:        gcc 2.95.1
>Organization:
>Environment:
sparc-sun-solaris2.6
>Description:
I want to compile a c++-program, which includes
'iostream.h'. I get the following errors:

/opt/gcc-2.95.1/include/g++/iostream.h:50: invalid type `void *' for default argument to `ostream *'
/opt/gcc-2.95.1/include/g++/iostream.h:123: invalid type `void *' for default argument to `ostream *'
/opt/gcc-2.95.1/include/g++/iostream.h:231: invalid type `void *' for default argument to `ostream *'

and the compiling ends.
This means: The default argument NULL is not of type 'ostream*'.

With 'gcc 2.8.1' i gets the same messages, but they
were only warnings.
How can i fix it? The changing of the "standard includes"
is a bad idea.

Thanks,
Andreas
>How-To-Repeat:

>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:
>From bkoz@cygnus.com Thu Oct 14 09:07:00 1999
From: Benjamin Kosnik <bkoz@cygnus.com>
To: nobody@sourceware.cygnus.com
Cc: libstdc++-prs@sourceware.cygnus.com
Subject: Re: libstdc++/11: invalid type for default argument
Date: Thu, 14 Oct 1999 09:07:00 -0000
Message-id: <19991014160700.17258.qmail@sourceware.cygnus.com>
X-SW-Source: 1999-q4/msg00001.html
Content-length: 486

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

From: Benjamin Kosnik <bkoz@cygnus.com>
To: aschmidt@lynet.de
Cc: libstdc++-gnats@sourceware.cygnus.com
Subject: Re: libstdc++/11: invalid type for default argument
Date: Thu, 14 Oct 1999 09:00:33 -0700 (PDT)

 Try including just <iostream>, not <iostream.h>
 
 Also, please include a sample program so that we can verify your problem.
 I have no idea what what the specifics are.
 
 Thanks,
 Benjamin
 
 
 
>From michaelv@edifecs.com Fri Nov 12 20:47:00 1999
From: michaelv@edifecs.com
To: libstdc++-gnats@sourceware.cygnus.com
Subject: libstdc++/12: libstdc++ 2.90.6 doesn't build on FreeBSD 3.1
Date: Fri, 12 Nov 1999 20:47:00 -0000
Message-id: <19991113043901.7931.qmail@sourceware.cygnus.com>
X-SW-Source: 1999-q4/msg00002.html
Content-length: 2051

>Number:         12
>Category:       libstdc++
>Synopsis:       libstdc++ 2.90.6 doesn't build on FreeBSD 3.1
>Confidential:   no
>Severity:       critical
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Nov 12 20:47:01 PST 1999
>Closed-Date:
>Last-Modified:
>Originator:     michaelv@edifecs.com
>Release:        2.90.6
>Organization:
>Environment:
FreeBSD 3.1, gmake v3.77, gcc v2.95.2, Pentium 266, 64MB RAM
>Description:
Can't build on FreeBSD.  Part way through the build it comes up with undefined symbols:

gmake  all-recursive
gmake[1]: Entering directory `/usr/home/michaelv/projects/gnu/libstdc++-2.90.6'
Making all in math
gmake[2]: Entering directory `/usr/home/michaelv/projects/gnu/libstdc++-2.90.6/math'
gmake[2]: Nothing to be done for `all'.
gmake[2]: Leaving directory `/usr/home/michaelv/projects/gnu/libstdc++-2.90.6/math'
Making all in string
gmake[2]: Entering directory `/usr/home/michaelv/projects/gnu/libstdc++-2.90.6/string'
/bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -c wmemcmp.c
rm -f .libs/wmemcmp.lo
gcc -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -c  -fPIC -DPIC wmemcmp.c -o .libs/wmemcmp.lo
wmemcmp.c: In function `wmemcmp':
wmemcmp.c:36: `wint_t' undeclared (first use in this function)
wmemcmp.c:36: (Each undeclared identifier is reported only once
wmemcmp.c:36: for each function it appears in.)
wmemcmp.c:36: parse error before `c1'
wmemcmp.c:41: `c1' undeclared (first use in this function)
wmemcmp.c:41: parse error before `s1'
wmemcmp.c:42: `c2' undeclared (first use in this function)
wmemcmp.c:42: parse error before `s2'
gmake[2]: *** [wmemcmp.lo] Error 1
gmake[2]: Leaving directory `/usr/home/michaelv/projects/gnu/libstdc++-2.90.6/string'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory `/usr/home/michaelv/projects/gnu/libstdc++-2.90.6'
gmake: *** [all-recursive-am] Error 2

>How-To-Repeat:
Try to build on FreeBSD
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:
>From bkoz@cygnus.com Fri Nov 12 21:57:00 1999
From: Benjamin Kosnik <bkoz@cygnus.com>
To: nobody@sourceware.cygnus.com
Cc: libstdc++-prs@sourceware.cygnus.com
Subject: Re: libstdc++/12: libstdc++ 2.90.6 doesn't build on FreeBSD 3.1
Date: Fri, 12 Nov 1999 21:57:00 -0000
Message-id: <19991113055700.15849.qmail@sourceware.cygnus.com>
X-SW-Source: 1999-q4/msg00003.html
Content-length: 390

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

From: Benjamin Kosnik <bkoz@cygnus.com>
To: michaelv@edifecs.com
Cc: libstdc++-gnats@sourceware.cygnus.com
Subject: Re: libstdc++/12: libstdc++ 2.90.6 doesn't build on FreeBSD 3.1
Date: Fri, 12 Nov 1999 21:56:37 -0800 (PST)

 try CVS libstdc++, as changes went in after 2.90.6x that effect wchar_t.
 
 -benjamin
>From michaelv@edifecs.com Mon Nov 15 19:27:00 1999
From: michaelv@edifecs.com
To: libstdc++-gnats@sourceware.cygnus.com
Subject: libstdc++/13: make install does not work on Solaris 2.6
Date: Mon, 15 Nov 1999 19:27:00 -0000
Message-id: <19991116032222.7809.qmail@sourceware.cygnus.com>
X-SW-Source: 1999-q4/msg00004.html
Content-length: 3646

>Number:         13
>Category:       libstdc++
>Synopsis:       make install does not work on Solaris 2.6
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Nov 15 19:27:00 PST 1999
>Closed-Date:
>Last-Modified:
>Originator:     michaelv@edifecs.com
>Release:        2.90.6 and CVS sources from 11/15/99
>Organization:
>Environment:
Solaris 2.6, SUNWspro 5.0 installed but not used, gcc 2.95.2, gmake 3.76.1 (also tried 3.77 and 3.78 with no change), bash 2.03.0(1)
>Description:
The libstdc++ builds fine, but when I try to do a "make install", it fails trying to install the headers:

Making install in math
gmake[1]: Entering directory `/export1/libstdc++/math'
gmake[2]: Entering directory `/export1/libstdc++/math'
gmake[2]: Nothing to be done for `install-exec-am'.
gmake[2]: Nothing to be done for `install-data-am'.
gmake[2]: Leaving directory `/export1/libstdc++/math'
gmake[1]: Leaving directory `/export1/libstdc++/math'
Making install in string
gmake[1]: Entering directory `/export1/libstdc++/string'
gmake[2]: Entering directory `/export1/libstdc++/string'
gmake[2]: Nothing to be done for `install-exec-am'.
gmake[2]: Nothing to be done for `install-data-am'.
gmake[2]: Leaving directory `/export1/libstdc++/string'
gmake[1]: Leaving directory `/export1/libstdc++/string'
Making install in libio
gmake[1]: Entering directory `/export1/libstdc++/libio'
gmake[2]: Entering directory `/export1/libstdc++/libio'
gmake[2]: Nothing to be done for `install-exec-am'.
gmake[2]: Nothing to be done for `install-data-am'.
gmake[2]: Leaving directory `/export1/libstdc++/libio'
gmake[1]: Leaving directory `/export1/libstdc++/libio'
Making install in src
gmake[1]: Entering directory `/export1/libstdc++/src'
gmake[2]: Entering directory `/export1/libstdc++/src'
/bin/sh ../mkinstalldirs /usr/local/lib
/bin/sh ../libtool  --mode=install .././install-sh -c libstdc++.la /usr/local/lib/libstdc++.la
.././install-sh -c .libs/libstdc++.so.3.0.0 /usr/local/lib/libstdc++.so.3.0.0
(cd /usr/local/lib && rm -f libstdc++.so.3 && ln -s libstdc++.so.3.0.0 libstdc++.so.3)
(cd /usr/local/lib && rm -f libstdc++.so && ln -s libstdc++.so.3.0.0 libstdc++.so)
chmod +x /usr/local/lib/libstdc++.so.3.0.0
.././install-sh -c .libs/libstdc++.lai /usr/local/lib/libstdc++.la
.././install-sh -c .libs/libstdc++.a /usr/local/lib/libstdc++.a
ranlib /usr/local/lib/libstdc++.a
chmod 644 /usr/local/lib/libstdc++.a
----------------------------------------------------------------------
Libraries have been installed in:
   /usr/local/lib

If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use `-LLIBDIR'
flag during linking and do at least one of the following:
   - add LIBDIR to the `LD_LIBRARY_PATH' environment variable
     during execution
   - use the `-RLIBDIR' linker flag

See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.
----------------------------------------------------------------------
gmake[2]: Nothing to be done for `install-data-am'.
gmake[2]: Leaving directory `/export1/libstdc++/src'
gmake[1]: *** No rule to make target `bits/basic_string.h', needed by `/usr/local/include/g++-v3/bits/basic_string.h'.  Stop.
gmake[1]: Leaving directory `/export1/libstdc++/src'
gmake: *** [install-recursive] Error 1
>How-To-Repeat:
Doing make install will fail every time.
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:
>From michaelv@edifecs.com Tue Nov 16 22:07:00 1999
From: michaelv@edifecs.com
To: libstdc++-gnats@sourceware.cygnus.com
Subject: libstdc++/14: Cannot link if std::stringstream is used
Date: Tue, 16 Nov 1999 22:07:00 -0000
Message-id: <19991117060433.16298.qmail@sourceware.cygnus.com>
X-SW-Source: 1999-q4/msg00005.html
Content-length: 2687

>Number:         14
>Category:       libstdc++
>Synopsis:       Cannot link if std::stringstream is used
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Nov 16 22:07:00 PST 1999
>Closed-Date:
>Last-Modified:
>Originator:     michaelv@edifecs.com
>Release:        CVS souce from 11/15/99
>Organization:
>Environment:
Solaris 2.6, gcc 2.95.2
>Description:
If I use std::stringstream in a program, I get multiple undefind symbols.  The errors are:

Undefined			first referenced
 symbol  			    in file
collate<wchar_t> type_info function /var/tmp/ccfEVnBc.o
collate<char> type_info function    /var/tmp/ccfEVnBc.o
locale::classic(void)               /var/tmp/ccfEVnBc.o
locale::_S_global                   /var/tmp/ccfEVnBc.o
locale::operator==(locale const &) const/var/tmp/ccfEVnBc.o
ios_base::ios_base(void)            /var/tmp/ccfEVnBc.o
ctype<wchar_t> type_info node       /var/tmp/ccfEVnBc.o
ctype<char> type_info node          /var/tmp/ccfEVnBc.o
locale::_Impl::~_Impl(void)         /var/tmp/ccfEVnBc.o
collate<char> type_info node        /var/tmp/ccfEVnBc.o
collate<wchar_t> type_info node     /var/tmp/ccfEVnBc.o
basic_ios<char, char_traits<char> >::init(basic_streambuf<char, char_traits<char> > *)/var/tmp/ccfEVnBc.o
ctype<char> const & use_facet<ctype<char> >(locale const &)/var/tmp/ccfEVnBc.o
ctype<wchar_t> type_info function   /var/tmp/ccfEVnBc.o
ctype<char> type_info function      /var/tmp/ccfEVnBc.o
locale::_S_classic                  /var/tmp/ccfEVnBc.o
ios_base::failure::failure(basic_string<char, char_traits<char>, allocator<char> > const &)/var/tmp/ccfEVnBc.o
locale::operator=(locale const &)   /var/tmp/ccfEVnBc.o
ios_base::~ios_base(void)           /var/tmp/ccfEVnBc.o
ld: fatal: Symbol referencing errors. No output written to sst
collect2: ld returned 1 exit status

>How-To-Repeat:
Try to compile/link this program, setting the #defines as appropriate:

#include <cstdlib>
#include <cstdio>

#include <string>

#ifdef DO_SSTREAM
#include <sstream>
#endif


int main()
{
    std::string str;
    str = "abc";
    str += "123";
    printf("str: %s\n", str.c_str());

#ifdef DO_WIDE
    std::wstring wstr;
    wstr = L"xyz";
    wstr += L"890";
    printf("wstr: %S\n", wstr.c_str());
#endif

#ifdef DO_SSTREAM
    std::stringstream ss;
    ss.str() = "abc";
    ss << 123;
    printf("ss: %s\n", ss.str().c_str());

#ifdef DO_WIDE
    std::wstringstream wss;
    wss.str() = L"xyz";
    wss << 890;
    printf("wss: %S\n", wss.str().c_str());
#endif
#endif

    return 0;
}

>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:
>From crash@cygnus.com Thu Nov 18 19:07:00 1999
From: Jason Molenda <crash@cygnus.com>
To: nobody@sourceware.cygnus.com
Cc: libstdc++-prs@sourceware.cygnus.com
Subject: Re: libstdc++/14
Date: Thu, 18 Nov 1999 19:07:00 -0000
Message-id: <19991119030700.9796.qmail@sourceware.cygnus.com>
X-SW-Source: 1999-q4/msg00007.html
Content-length: 881

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

From: Jason Molenda <crash@cygnus.com>
To: libstdc++-gnats@sourceware.cygnus.com
Cc:  
Subject: Re: libstdc++/14
Date: Thu, 18 Nov 1999 19:05:50 -0800

 ----- Forwarded message from Michael VanLoon <MichaelV@EDIFECS.COM> -----
 
 Date: Thu, 18 Nov 1999 14:12:27 -0800
 From: Michael VanLoon <MichaelV@EDIFECS.COM>
 To: "'libstdc++-gnats@sourceware.cygnus.com'" <libstdc++-gnats@sourceware.cygnus.com>,
         "'nobody@sourceware.cygnus.com'" <nobody@sourceware.cygnus.com>
 Subject: pending/15: Re: libstdc++/libstdc++/14
 
  It appears I can't even update my own bug report.
  
  This bug report is bogus.  I discovered that I was using the new headers,
  but still linking against the old library.  Once I linked against the new
  library, this went away.  FYI.
 
 ----- End forwarded message -----
>From jsm@cygnus.com Thu Nov 18 19:07:00 1999
From: jsm@cygnus.com
To: nobody@sourceware.cygnus.com
Cc: libstdc++-prs@sourceware.cygnus.com
Subject: Re: libstdc++/15
Date: Thu, 18 Nov 1999 19:07:00 -0000
Message-id: <19991119030700.9801.qmail@sourceware.cygnus.com>
X-SW-Source: 1999-q4/msg00006.html
Content-length: 565

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

From: jsm@cygnus.com
To: MichaelV@EDIFECS.COM, libstdc++-gnats@sourceware.cygnus.com,
  nobody@sourceware.cygnus.com
Cc:  
Subject: Re: libstdc++/15
Date: 19 Nov 1999 03:06:28 -0000

 Synopsis: Re: libstdc++/libstdc++/14
 
 State-Changed-From-To: open->closed
 State-Changed-By: jsm
 State-Changed-When: Thu Nov 18 19:06:28 1999
 State-Changed-Why:
     Errant PR; a follow-up e-mail got misdirected.
 
 http://sourceware.cygnus.com/cgi-bin/gnatsweb.pl?cmd=view&pr=15&database=libstdc++
>From Chad_Gibbons@bmc.com Mon Nov 22 10:57:00 1999
From: Chad_Gibbons@bmc.com
To: libstdc++-gnats@sourceware.cygnus.com
Subject: libstdc++/16: ios initialization bug
Date: Mon, 22 Nov 1999 10:57:00 -0000
Message-id: <19991122185103.8044.qmail@sourceware.cygnus.com>
X-SW-Source: 1999-q4/msg00008.html
Content-length: 2008

>Number:         16
>Category:       libstdc++
>Synopsis:       ios initialization bug
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Nov 22 10:57:00 PST 1999
>Closed-Date:
>Last-Modified:
>Originator:     Chad_Gibbons@bmc.com
>Release:        2.90.6
>Organization:
>Environment:
sparc Solaris 7, gcc 2.95.0 / 2.95.2, gld 2.9
>Description:
While using v2.90.6 of libstdc++, I have run into a situation where the normal startup of the I/O stream library is run out of order. I believe this might be the result of an incorrect assumption in the library.

If <iostream> is included in any module, a static member is added from std_iostream.h:
    // For construction of filebuffers for cout, cin, cerr, clog et. al.
    static ios_base::Init __ioinit;

The constructor for this object creates the file buffers for the standard I/O stream objects and sets their references via rdbuf. If, however, the constructors for those standard I/O stream objects occurs after the first
call to ios_base::Init::Init(), then the pointers to these buffers are overridden and all stream operations via those objects are disabled.

In practice, I have only seen this in extremely large projects (on the order of 50,000 symbols). For whatever Reason, the compiler/linker selects several modules that are initialized before the libstdc++ modules. These modules
have no static data, no references to static objects, and are themselves not referenced statically -- they just happen to include <iostream>.

In any event, it seems the library is relying on the compiler to construct cout/cin/etc. before ios_base::Init is constructed, and that is something the language doesn't guarantee (I believe).

>How-To-Repeat:
I have not been able to cause the ctor list to be created in a way that exhibits this behavior unless a large project is built.
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:
>From bkoz@cygnus.com Mon Nov 22 11:07:00 1999
From: Benjamin Kosnik <bkoz@cygnus.com>
To: nobody@sourceware.cygnus.com
Cc: libstdc++-prs@sourceware.cygnus.com
Subject: Re: libstdc++/16: ios initialization bug
Date: Mon, 22 Nov 1999 11:07:00 -0000
Message-id: <19991122190700.10709.qmail@sourceware.cygnus.com>
X-SW-Source: 1999-q4/msg00009.html
Content-length: 1801

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

From: Benjamin Kosnik <bkoz@cygnus.com>
To: Chad_Gibbons@bmc.com
Cc: libstdc++-gnats@sourceware.cygnus.com
Subject: Re: libstdc++/16: ios initialization bug
Date: Mon, 22 Nov 1999 11:06:28 -0800 (PST)

 Chad. 
 
 Thanks for your bug report. Unfortunately, the snapshot you are using is 
 a bit dated now, and some of the changes that have happened in the three 
 months since we last released affected the ios_base::init member. I 
 strongly urge you to check out the CVS sources and give it a whirl, as it 
 also includes such things as floating point output, and lots of 
 stringstream fixes. 
 
 
 > The constructor for this object creates the file buffers for the standard I/O stream objects and sets their references via rdbuf. If, however, the constructors for those standard I/O stream objects occurs after the first
 > call to ios_base::Init::Init(), then the pointers to these buffers are overridden and all stream operations via those objects are disabled.
 > 
 > In practice, I have only seen this in extremely large projects (on the order of 50,000 symbols). For whatever Reason, the compiler/linker selects several modules that are initialized before the libstdc++ modules. These modules
 > have no static data, no references to static objects, and are themselves not referenced statically -- they just happen to include <iostream>.
 > 
 > In any event, it seems the library is relying on the compiler to construct cout/cin/etc. before ios_base::Init is constructed, and that is something the language doesn't guarantee (I believe).
 
 27.3 iostream objects goes over this requirement. I belive CVS sources 
 now get this behavior correct, but know that the release you are using 
 has problems. 
 
 -benjamin
>From bkoz@cygnus.com Thu Dec 02 11:07:00 1999
From: Benjamin Kosnik <bkoz@cygnus.com>
To: nobody@sourceware.cygnus.com
Cc: libstdc++-prs@sourceware.cygnus.com
Subject: RE: libstdc++/16: ios initialization bug
Date: Thu, 02 Dec 1999 11:07:00 -0000
Message-id: <19991202190659.11101.qmail@sourceware.cygnus.com>
X-SW-Source: 1999-q4/msg00010.html
Content-length: 5054

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: ios initialization bug
Date: Thu, 2 Dec 1999 10:59:06 -0800 (PST)

 hmmm. If this static init object is in the iostream header, then the
 initialization of the iostream std objects will take place before people
 can use things like cout/cin/cerr (as they'd need the declarations in the
 iostream header). 
 
 If this is put into a source file, no such guarantees are in place. I
 don't believe you sent me a small, reproducable test case for this (but
 maybe I'm wrong) -- can you either correct me (I admit to being
 particularly flaky about this bug report, sorry) or construct one and send
 it to me?
 
 -benjamin
  
 
 On Thu, 2 Dec 1999, Gibbons, Chad wrote:
 
 > Benjamin,
 > 
 > Here's the patch I'm using. It seems to work fine on our code, but I wasn't
 > able to run the testsuite at all (even before the patch!) to try it out...
 > 
 > Index: bits/std_iostream.h
 > ===================================================================
 > RCS file: /cvs/libstdc++/libstdc++/bits/std_iostream.h,v
 > retrieving revision 1.11
 > diff -c -3 -p -d -r1.11 std_iostream.h
 > *** std_iostream.h      1999/06/25 03:55:41     1.11
 > --- std_iostream.h      1999/12/02 18:11:01
 > *************** namespace std {
 > *** 50,58 ****
 >     extern wostream wcerr;
 >     extern wostream wclog;
 >   #endif
 > - 
 > -   // For construction of filebuffers for cout, cin, cerr, clog et. al.
 > -   static ios_base::Init __ioinit;
 >   } // namespace std
 >   
 >   #endif        /* _CPP_IOSTREAM */
 > --- 50,55 ----
 > Index: src/stdstreams.cc
 > ===================================================================
 > RCS file: /cvs/libstdc++/libstdc++/src/stdstreams.cc,v
 > retrieving revision 1.11
 > diff -c -3 -p -d -r1.11 stdstreams.cc
 > *** stdstreams.cc       1999/06/25 03:56:04     1.11
 > --- stdstreams.cc       1999/12/02 18:11:02
 > *************** namespace std {
 > *** 45,48 ****
 > --- 45,51 ----
 >     wostream wclog(&__wfileinit);
 >   #endif
 >    
 > +    // For construction of filebuffers for cout, cin, cerr, clog et. al.
 > +    static ios_base::Init __ioinit;
 > + 
 >   } // std
 > 
 > 
 > 
 > -----Original Message-----
 > From: Benjamin Kosnik [ mailto:bkoz@cygnus.com ]
 > Sent: Wednesday, December 01, 1999 11:53 PM
 > To: Gibbons, Chad
 > Subject: RE: libstdc++/16: ios initialization bug
 > 
 > 
 > 
 > aggh. Sorry. I just got back. Can you resend your patch please? I got a 
 > bit behind.
 > 
 > -benjamin
 > 
 > On Wed, 1 Dec 1999, Gibbons, Chad wrote:
 > 
 > > Hiya Benjamin,
 > > 
 > > I sent you a message back last week or so with a pseudo-patch for this
 > > problem. Would it be best for me to submit a patch in the way described at
 > > http://sourceware.cygnus.com/libstdc++/17_intro/contribute.html ?
 > > 
 > > By the way, the latest CVS sources still exhibit the behavior.
 > > 
 > > Thanks again,
 > > Chad Gibbons
 > > 
 > > -----Original Message-----
 > > From: Benjamin Kosnik [ mailto:bkoz@cygnus.com ]
 > > Sent: Monday, November 22, 1999 1:06 PM
 > > To: Chad_Gibbons@bmc.com
 > > Cc: libstdc++-gnats@sourceware.cygnus.com
 > > Subject: Re: libstdc++/16: ios initialization bug
 > > 
 > > 
 > > 
 > > Chad. 
 > > 
 > > Thanks for your bug report. Unfortunately, the snapshot you are using is 
 > > a bit dated now, and some of the changes that have happened in the three 
 > > months since we last released affected the ios_base::init member. I 
 > > strongly urge you to check out the CVS sources and give it a whirl, as it 
 > > also includes such things as floating point output, and lots of 
 > > stringstream fixes. 
 > > 
 > > 
 > > > The constructor for this object creates the file buffers for the
 > standard
 > > I/O stream objects and sets their references via rdbuf. If, however, the
 > > constructors for those standard I/O stream objects occurs after the first
 > > > call to ios_base::Init::Init(), then the pointers to these buffers are
 > > overridden and all stream operations via those objects are disabled.
 > > > 
 > > > In practice, I have only seen this in extremely large projects (on the
 > > order of 50,000 symbols). For whatever Reason, the compiler/linker selects
 > > several modules that are initialized before the libstdc++ modules. These
 > > modules
 > > > have no static data, no references to static objects, and are themselves
 > > not referenced statically -- they just happen to include <iostream>.
 > > > 
 > > > In any event, it seems the library is relying on the compiler to
 > construct
 > > cout/cin/etc. before ios_base::Init is constructed, and that is something
 > > the language doesn't guarantee (I believe).
 > > 
 > > 27.3 iostream objects goes over this requirement. I belive CVS sources 
 > > now get this behavior correct, but know that the release you are using 
 > > has problems. 
 > > 
 > > -benjamin
 > > 
 > 
 
>From Chad_Gibbons@bmc.com Thu Dec 02 12:17:00 1999
From: "Gibbons, Chad" <Chad_Gibbons@bmc.com>
To: nobody@sourceware.cygnus.com
Cc: libstdc++-prs@sourceware.cygnus.com
Subject: RE: libstdc++/16: ios initialization bug
Date: Thu, 02 Dec 1999 12:17:00 -0000
Message-id: <19991202201700.23722.qmail@sourceware.cygnus.com>
X-SW-Source: 1999-q4/msg00011.html
Content-length: 6566

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

From: "Gibbons, Chad" <Chad_Gibbons@bmc.com>
To: "'Benjamin Kosnik'" <bkoz@cygnus.com>,
        "Gibbons, Chad"
	 <Chad_Gibbons@ec01-hou.bmc.com>
Cc: libstdc++-gnats@sourceware.cygnus.com
Subject: RE: libstdc++/16: ios initialization bug
Date: Thu, 2 Dec 1999 14:15:00 -0600 

 Unfortunately, I don't have a small test program that can break the ios
 initialization code. We only see the behavior in an application that has an
 extremely large number of symbols (which causes g++/gld to place the ctors
 for some objects before the creation of the iostream objects). Our original
 problem was with code that was including <iostream> and even though they
 didn't use it early on, it caused global constructors to be called for that
 module.
 
 If this line:
     static ios_base::Init __ioinit;
 is left in bits/std_iostream.h, then it is possible (on compiler/linker
 whims) for it to be called before the cout/cerr/etc. constructors are
 called. Once the constructors for those global objects are called, the file
 buffers that were created by ios_base::Init are replaced with null pointers.
 
 By moving the line above to src/stdstreams.cc, I was forcing the
 initialization of the file buffers to occur after the iostream objects are
 actually created. Since the initialization of the buffers is tied to the
 iostream's creation, you're still safe if a user tries to use ios early on
 (they can't use them any earlier than they've been constructed...).
 
 Thanks,
 Chad Gibbons
 
 -----Original Message-----
 From: Benjamin Kosnik [ mailto:bkoz@cygnus.com ]
 Sent: Thursday, December 02, 1999 12:59 PM
 To: Gibbons, Chad
 Cc: libstdc++-gnats@sourceware.cygnus.com
 Subject: RE: libstdc++/16: ios initialization bug
 
 
 
 hmmm. If this static init object is in the iostream header, then the
 initialization of the iostream std objects will take place before people
 can use things like cout/cin/cerr (as they'd need the declarations in the
 iostream header). 
 
 If this is put into a source file, no such guarantees are in place. I
 don't believe you sent me a small, reproducable test case for this (but
 maybe I'm wrong) -- can you either correct me (I admit to being
 particularly flaky about this bug report, sorry) or construct one and send
 it to me?
 
 -benjamin
  
 
 On Thu, 2 Dec 1999, Gibbons, Chad wrote:
 
 > Benjamin,
 > 
 > Here's the patch I'm using. It seems to work fine on our code, but I
 wasn't
 > able to run the testsuite at all (even before the patch!) to try it out...
 > 
 > Index: bits/std_iostream.h
 > ===================================================================
 > RCS file: /cvs/libstdc++/libstdc++/bits/std_iostream.h,v
 > retrieving revision 1.11
 > diff -c -3 -p -d -r1.11 std_iostream.h
 > *** std_iostream.h      1999/06/25 03:55:41     1.11
 > --- std_iostream.h      1999/12/02 18:11:01
 > *************** namespace std {
 > *** 50,58 ****
 >     extern wostream wcerr;
 >     extern wostream wclog;
 >   #endif
 > - 
 > -   // For construction of filebuffers for cout, cin, cerr, clog et. al.
 > -   static ios_base::Init __ioinit;
 >   } // namespace std
 >   
 >   #endif        /* _CPP_IOSTREAM */
 > --- 50,55 ----
 > Index: src/stdstreams.cc
 > ===================================================================
 > RCS file: /cvs/libstdc++/libstdc++/src/stdstreams.cc,v
 > retrieving revision 1.11
 > diff -c -3 -p -d -r1.11 stdstreams.cc
 > *** stdstreams.cc       1999/06/25 03:56:04     1.11
 > --- stdstreams.cc       1999/12/02 18:11:02
 > *************** namespace std {
 > *** 45,48 ****
 > --- 45,51 ----
 >     wostream wclog(&__wfileinit);
 >   #endif
 >    
 > +    // For construction of filebuffers for cout, cin, cerr, clog et. al.
 > +    static ios_base::Init __ioinit;
 > + 
 >   } // std
 > 
 > 
 > 
 > -----Original Message-----
 > From: Benjamin Kosnik [ mailto:bkoz@cygnus.com ]
 > Sent: Wednesday, December 01, 1999 11:53 PM
 > To: Gibbons, Chad
 > Subject: RE: libstdc++/16: ios initialization bug
 > 
 > 
 > 
 > aggh. Sorry. I just got back. Can you resend your patch please? I got a 
 > bit behind.
 > 
 > -benjamin
 > 
 > On Wed, 1 Dec 1999, Gibbons, Chad wrote:
 > 
 > > Hiya Benjamin,
 > > 
 > > I sent you a message back last week or so with a pseudo-patch for this
 > > problem. Would it be best for me to submit a patch in the way described
 at
 > > http://sourceware.cygnus.com/libstdc++/17_intro/contribute.html ?
 > > 
 > > By the way, the latest CVS sources still exhibit the behavior.
 > > 
 > > Thanks again,
 > > Chad Gibbons
 > > 
 > > -----Original Message-----
 > > From: Benjamin Kosnik [ mailto:bkoz@cygnus.com ]
 > > Sent: Monday, November 22, 1999 1:06 PM
 > > To: Chad_Gibbons@bmc.com
 > > Cc: libstdc++-gnats@sourceware.cygnus.com
 > > Subject: Re: libstdc++/16: ios initialization bug
 > > 
 > > 
 > > 
 > > Chad. 
 > > 
 > > Thanks for your bug report. Unfortunately, the snapshot you are using is
 
 > > a bit dated now, and some of the changes that have happened in the three
 
 > > months since we last released affected the ios_base::init member. I 
 > > strongly urge you to check out the CVS sources and give it a whirl, as
 it 
 > > also includes such things as floating point output, and lots of 
 > > stringstream fixes. 
 > > 
 > > 
 > > > The constructor for this object creates the file buffers for the
 > standard
 > > I/O stream objects and sets their references via rdbuf. If, however, the
 > > constructors for those standard I/O stream objects occurs after the
 first
 > > > call to ios_base::Init::Init(), then the pointers to these buffers are
 > > overridden and all stream operations via those objects are disabled.
 > > > 
 > > > In practice, I have only seen this in extremely large projects (on the
 > > order of 50,000 symbols). For whatever Reason, the compiler/linker
 selects
 > > several modules that are initialized before the libstdc++ modules. These
 > > modules
 > > > have no static data, no references to static objects, and are
 themselves
 > > not referenced statically -- they just happen to include <iostream>.
 > > > 
 > > > In any event, it seems the library is relying on the compiler to
 > construct
 > > cout/cin/etc. before ios_base::Init is constructed, and that is
 something
 > > the language doesn't guarantee (I believe).
 > > 
 > > 27.3 iostream objects goes over this requirement. I belive CVS sources 
 > > now get this behavior correct, but know that the release you are using 
 > > has problems. 
 > > 
 > > -benjamin
 > > 
 > 
>From pbd@op.net Fri Dec 03 17:57:00 1999
From: pbd@op.net
To: libstdc++-gnats@sourceware.cygnus.com
Subject: libstdc++/17: cout is not a real ostream; dynamic_cast SEGV's as a result
Date: Fri, 03 Dec 1999 17:57:00 -0000
Message-id: <19991204015556.7643.qmail@sourceware.cygnus.com>
X-SW-Source: 1999-q4/msg00012.html
Content-length: 1601

>Number:         17
>Category:       libstdc++
>Synopsis:       cout is not a real ostream; dynamic_cast SEGV's as a result
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Dec 03 17:57:00 PST 1999
>Closed-Date:
>Last-Modified:
>Originator:     pbd@op.net
>Release:        2.9.0
>Organization:
>Environment:
RedHat Linux, egcs 1.1.2
>Description:
because cout is not a real ostream, but a _fake_ostream,
dynamic_cast<ClassDerivedFromOstream *> will fail
when applied to a pointer or reference to cout.

given that "ostream cout" is apparently part of the
"standard library", not having cout actually be a
real ostream is not good. 

i think. :)
>How-To-Repeat:
compile this program: c++ -o k.k.cc
run it, watch it SEGV when attempting a dynamic cast
on the pointer to cout.
>Fix:
cout should be a real ostream, not a _fake_ostream.
>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: application/octet-stream; name="k.cc"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="k.cc"

I2luY2x1ZGUgPGlvc3RyZWFtPgoKY2xhc3MgVHJhbnNtaXR0ZXIgOiBwdWJsaWMgb3N0cmVhbQoK
ewp9OwoKdm9pZCAKdHJ5X2Nhc3QgKG9zdHJlYW0gKm9zdHIpCgp7CglUcmFuc21pdHRlciAqdHA7
CgoJdHAgPSBkeW5hbWljX2Nhc3Q8VHJhbnNtaXR0ZXIgKj4gKG9zdHIpOwoJY291dCA8PCAidHAg
PSAiIDw8IGhleCA8PCAoaW50KSB0cCA8PCBkZWMgPDwgZW5kbDsKfQkKCm1haW4gKCkKCnsKCVRy
YW5zbWl0dGVyIHQ7Cglvc3RyZWFtIGZvbzsKCgl0cnlfY2FzdCAoJnQpOwoJdHJ5X2Nhc3QgKCZm
b28pOwoJdHJ5X2Nhc3QgKCZjb3V0KTsKfQoJCg==
>From bkoz@cygnus.com Fri Dec 03 20:07:00 1999
From: Benjamin Kosnik <bkoz@cygnus.com>
To: nobody@sourceware.cygnus.com
Cc: libstdc++-prs@sourceware.cygnus.com
Subject: Re: libstdc++/17: cout is not a real ostream; dynamic_cast SEGV's as a result
Date: Fri, 03 Dec 1999 20:07:00 -0000
Message-id: <19991204040700.18090.qmail@sourceware.cygnus.com>
X-SW-Source: 1999-q4/msg00013.html
Content-length: 659

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

From: Benjamin Kosnik <bkoz@cygnus.com>
To: pbd@op.net
Cc: libstdc++-gnats@sourceware.cygnus.com
Subject: Re: libstdc++/17: cout is not a real ostream; dynamic_cast SEGV's as a result
Date: Fri, 3 Dec 1999 20:01:52 -0800 (PST)

 > because cout is not a real ostream, but a _fake_ostream,
 > dynamic_cast<ClassDerivedFromOstream *> will fail
 > when applied to a pointer or reference to cout.
 
 see http://sourceware.cygnus.com/libstdc++
 
 that's what this database is for. . . . if you checkout the CVS sources, 
 you'll see that cout is indeed a "real" ostream
 
 
 -benjamin
 
>From pbd@Op.Net Fri Dec 03 21:37:00 1999
From: Paul Barton-Davis <pbd@Op.Net>
To: nobody@sourceware.cygnus.com
Cc: libstdc++-prs@sourceware.cygnus.com
Subject: Re: libstdc++/17: cout is not a real ostream; dynamic_cast SEGV's as a result 
Date: Fri, 03 Dec 1999 21:37:00 -0000
Message-id: <19991204053700.24756.qmail@sourceware.cygnus.com>
X-SW-Source: 1999-q4/msg00015.html
Content-length: 1140

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

From: Paul Barton-Davis <pbd@Op.Net>
To: Benjamin Kosnik <bkoz@cygnus.com>
Cc: libstdc++-gnats@sourceware.cygnus.com
Subject: Re: libstdc++/17: cout is not a real ostream; dynamic_cast SEGV's as a result 
Date: Sat, 04 Dec 1999 00:35:55 -0500

 Also:
 
 >that's what this database is for. . . . if you checkout the CVS sources, 
 >you'll see that cout is indeed a "real" ostream
 
 When i use the web-browsing access to the CVS source, i find this in
 v1.1 of stdstream.cc:
 
 ----------------------------------------------------------
 struct _fake_ostream {
        ....
 };
 
   .
   . 
   .
 
 #ifdef __GNUC__
 #define OSTREAM_DEF(NAME, SBUF, TIE, EXTRA_FLAGS, ASM) \
   _fake_ostream NAME ASM = { {&NAME.base}, {STD_STR(SBUF, TIE, EXTRA_FLAGS) }};
 #else
 #define OSTREAM_DEF(NAME, SBUF, TIE, EXTRA_FLAGS) \
   _fake_ostream NAME = { {0, &NAME.base}, {STD_STR(SBUF, TIE, EXTRA_FLAGS) }};
 #endif
    .
    .
    .
 
 OSTREAM_DEF(cout, COUT_SBUF, NULL, 0, )
 ----------------------------------------------------------
 
 what i am not seeing ? 
 
 --p
 
 
 
>From pbd@Op.Net Fri Dec 03 21:37:00 1999
From: Paul Barton-Davis <pbd@Op.Net>
To: nobody@sourceware.cygnus.com
Cc: libstdc++-prs@sourceware.cygnus.com
Subject: Re: libstdc++/17: cout is not a real ostream; dynamic_cast SEGV's as a result 
Date: Fri, 03 Dec 1999 21:37:00 -0000
Message-id: <19991204053700.24751.qmail@sourceware.cygnus.com>
X-SW-Source: 1999-q4/msg00014.html
Content-length: 893

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

From: Paul Barton-Davis <pbd@Op.Net>
To: Benjamin Kosnik <bkoz@cygnus.com>
Cc: libstdc++-gnats@sourceware.cygnus.com
Subject: Re: libstdc++/17: cout is not a real ostream; dynamic_cast SEGV's as a result 
Date: Sat, 04 Dec 1999 00:28:46 -0500

 >> because cout is not a real ostream, but a _fake_ostream,
 >> dynamic_cast<ClassDerivedFromOstream *> will fail
 >> when applied to a pointer or reference to cout.
 >
 >see http://sourceware.cygnus.com/libstdc++
 >
 >that's what this database is for. . . . if you checkout the CVS sources, 
 >you'll see that cout is indeed a "real" ostream
 
 then why does a dynamic_cast<ClassDerivedFromOstream *> segfault when
 passed a pointer to cout, but not to any other ostream ?
 
 perhaps i am getting my streams implementation from some other library
 like libg++ ?
 
 --p
>From vladimir.kondratiev@intel.com Thu Dec 16 00:47:00 1999
From: vladimir.kondratiev@intel.com
To: libstdc++-gnats@sourceware.cygnus.com
Subject: libstdc++/18: 2.90.7 release announced but not uploaded to FTP server
Date: Thu, 16 Dec 1999 00:47:00 -0000
Message-id: <19991216084059.14836.qmail@sourceware.cygnus.com>
X-SW-Source: 1999-q4/msg00016.html
Content-length: 551

>Number:         18
>Category:       libstdc++
>Synopsis:       2.90.7 release announced but not uploaded to FTP server
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    unassigned
>State:          open
>Class:          support
>Submitter-Id:   net
>Arrival-Date:   Thu Dec 16 00:47:00 PST 1999
>Closed-Date:
>Last-Modified:
>Originator:     vladimir.kondratiev@intel.com
>Release:        unknown-1.0
>Organization:
>Environment:

>Description:

>How-To-Repeat:

>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:
>From bkoz@cygnus.com Thu Dec 16 10:37:00 1999
From: Benjamin Kosnik <bkoz@cygnus.com>
To: nobody@sourceware.cygnus.com
Cc: libstdc++-prs@sourceware.cygnus.com
Subject: Re: libstdc++/18: 2.90.7 release announced but not uploaded to FTPserver
Date: Thu, 16 Dec 1999 10:37:00 -0000
Message-id: <19991216183700.26696.qmail@sourceware.cygnus.com>
X-SW-Source: 1999-q4/msg00017.html
Content-length: 417

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

From: Benjamin Kosnik <bkoz@cygnus.com>
To: vladimir.kondratiev@intel.com
Cc: libstdc++-gnats@sourceware.cygnus.com
Subject: Re: libstdc++/18: 2.90.7 release announced but not uploaded to FTP
 server
Date: Thu, 16 Dec 1999 10:33:48 -0800 (PST)

 The realse is not out, the web page is in error. It will probably be
 monday.
 
 -benjamin
 
>From tomoaki@biol.s.u-tokyo.ac.jp Sat Dec 25 08:17:00 1999
From: tomoaki@biol.s.u-tokyo.ac.jp
To: libstdc++-gnats@sourceware.cygnus.com
Subject: libstdc++/19: _T name colision to ctype.h in FreeBSD
Date: Sat, 25 Dec 1999 08:17:00 -0000
Message-id: <19991225161335.3927.qmail@sourceware.cygnus.com>
X-SW-Source: 1999-q4/msg00018.html
Content-length: 942

>Number:         19
>Category:       libstdc++
>Synopsis:       _T name colision to ctype.h in FreeBSD
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Sat Dec 25 08:17:00 PST 1999
>Closed-Date:
>Last-Modified:
>Originator:     tomoaki@biol.s.u-tokyo.ac.jp
>Release:        libstdc++-2.90.7
>Organization:
>Environment:
FreeBSD koke.nibb.ac.jp 3.3-RELEASE FreeBSD 3.3-RELEASE #0: Sun Nov 14 22:56:39 JST 1999     tomoaki@koke.nibb.ac.jp:/usr/src/sys/compile/PH  i386
>Description:
_T is defined as a macro in ctype.h in FreeBSD
bits/slice_array.h and some other files use
_T as a local identifier, but will be overriden
by the macro defined in ctype.h.
In many other locations, _Tp is used as a local identifier.
>How-To-Repeat:

>Fix:
Substitute _T with _Tp
>Release-Note:
>Audit-Trail:
>Unformatted: