HDTenEightyP/NetNews huggingface dataset:
From: mccrory@tomato.fnal.gov (Elliott McCrory)
Newsgroups: gnu.g++.help
Subject: static vals inside a class are unresolved (g++ 2.0/SunOS4.1.1)
Date: 9 Apr 92 21:16:31 GMT
Distribution: gnu
Organization: Fermilab, Batavia, IL

How has the use of "static" changed since g++ 1.39?  I have a
situation like this:

% cat world.cxx
#include <std.h>
#include <stream.h>

class Foo {
  static int a;
 public:
  Foo(int c) { a=c ; f=0.0; };
  int b() { return a; };
  static float f;
};

int main(int argc, char* argv[])
{
  Foo A(1);
  cout << A.b() << "Hello world\n" << A.f << "\n";
}

% make -k world
g++  -g -Dsun4 -DEBUG -o world world.cxx
world.cxx:7 (world.o): Undefined symbol __3Foo$a referenced from text segment
world.cxx:7 (world.o): Undefined symbol __3Foo$a referenced from text segment
world.cxx:7 (world.o): Undefined symbol __3Foo$f referenced from text segment
world.cxx:7 (world.o): Undefined symbol __3Foo$f referenced from text segment
world.cxx:8 (world.o): Undefined symbol __3Foo$a referenced from text segment
world.cxx:8 (world.o): Undefined symbol __3Foo$a referenced from text segment
world.cxx:15 (world.o): Undefined symbol __3Foo$f referenced from text segment
world.cxx:15 (world.o): Undefined symbol __3Foo$f referenced from text segment
*** Error code 1
make: Warning: Target `world' not remade because of errors

Compilation finished at Thu Apr  9 16:13:14

Thanks in advance.
--
  ||    Elliott McCrory, Ph. D.		| mccrory@tomato.fnal.gov (internet)
-/  \-  Fermi National Accelerator Lab	| ALMOND::MCCRORY	 (DECnet)
-\  /-  Batavia, IL  60510		| MCCRORY@FNALAD	 (BITnet)
  ||    708-840-4808			| linac!tomato!mccrory	 (uucp)
Newsgroups: gnu.g++.help,comp.lang.c++
From: auld@ssd.intel.com (William Auld)
Subject: Debugging C++ with gcc 2.1 producing COFF files and gdb.
Organization: Gatewayed from the GNU Project mailing list help-g++@prep.ai.mit.edu
Date: Mon, 13 Apr 1992 16:44:17 GMT

Will gdb be able to use what it knows about C++ with COFF file produced
by gcc 2.1?

Will
auld@ssd.intel.com
From: dic5340@hertz.njit.edu (David Charlap)
Newsgroups: gnu.g++.help
Subject: G++ and curses.h
Date: 8 Apr 92 18:46:06 GMT
Organization: New Jersey Institute of Technology, Newark, N.J.

I need to link the curses screen i/o package with g++ code.  So far,
the linker refuses.  I've been using the command line as specified in
the curses man page for cc:  "g++ test.C -lcurses -ltermcap".  This
fails in the link stage.

gcc works fine with those options on C code.  I found a curses.h in
the g++ include directory.  Is there a gnu-curses I must link with?
If so, what are the library names I need.

For the time being, I'm getting minimum functionality by using ioctl()
calls and termio.h.  But this doesn't offer anywhere near the
functionality I'll soon be requiring.
-- 
David Charlap                   Q:"Where do these stairs go?"
dic5340@hertz.njit.edu          A:"They go up"
----------------------------
Hi! I am a .signature virus. Copy me into your .signature to join in!
Newsgroups: gnu.g++.lib.bug
From: bothner@cygnus.com
Subject: Re: Problems Building libg++
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 5 Apr 1992 16:03:34 GMT

>From source file: "Regex.cc"; error in assembler file:
     line 521: Invalid type in .stabs

.stabs "___DTOR_LIST__",22,0,0,__GLOBAL_$D$__5RegexRC5Regex

Looks like you need to
	#define FASCIST_ASSEMBLER
in gcc/config/sequent.h.

	--Per Bothner
Cygnus Support     bothner@cygnus.com

Newsgroups: gnu.g++.lib.bug
From: venkat@concour.cs.concordia.ca (VENKATESH)
Subject: libg++-2.0 iostream
Keywords: libg++-2.0 iostream
Organization: Concordia University, Montreal, Quebec
Distribution: gnu
Date: Mon, 13 Apr 1992 23:24:02 GMT

I successfully installed gcc-2.1 for m88k-motorola-sysv3 configuration.
The changes I had to make were minor. I had to include -D_POSIX_SOURCE
option. I also installed libg++ using gcc-2.1.

I have problem in installing iostream. The compiler error is as follows:

gcc -I. -I./../g++-include -DUSG -D_POSIX_SOURCE -c iostream.C

iostream.C: In function `class streambuf::istream& operator >> (class streambuf::istream&, double &)':
iostream.C:298: conversion to non-scalar type requested

I have similar error at line 306 and in other function.
The source code where the error happens is:
is.rdbuf()->vsacn("%lg", (va_list)&ptr);

The va_list is a typedefed struct in m88k (include file va-m88k.h).

Could someone help me in fixing the problem.
Thanks in advance.
Venkatesh

Newsgroups: gnu.g++.lib.bug
From: mnl@idtsun.e-technik.TH-darmstadt.DE (Michael N. Lipp)
Subject: strstream bug in libg++-2.0
Organization: TH-Darmstadt
Distribution: gnu
Date: Wed, 8 Apr 1992 10:54:26 GMT

Hi,

the following program

----------------------------------------------------------------------
#include <stream.h>
#include <strstream.h>

main ()
{
  istrstream in ("Hello world!\n");

  char c;
  in.tellg ();
  while (in >> c, !in.eof ())
    cout << c;
}
----------------------------------------------------------------------

puts out nothing. This is caused by the call to in.tellg(). If this
is ommitted, it works. I have no description of the iostream library,
but it seems to me that tellg() should only report the position of the
get pointer and not change it?

Another thing: If I leave out the in.tellg(), I find that the default
seeting is "skip whitespace" (I get "Helloworld!"). Is this a bug or
a feature?

Michael

--
-----------------,------------------------------,------------------------------
Michael N. Lipp  !  Institut fuer Datentechnik  !  Phone: 49-6151-163776
                 !  Merckstr. 25     ,----------'  Fax:   49-6151-164976
                 !  D-6100 Darmstadt ! E-Mail:
                 !  (Germany)        !     mnl@dtro.e-technik.th-darmstadt.de
-----------------'-------------------'-----------------------------------------

Newsgroups: gnu.g++.lib.bug
From: axel@thor.informatik.uni-osnabrueck.de (Axel Schreiner)
Subject: (none)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 11 Apr 1992 09:33:25 GMT

For NeXT 2.1 the following patches make libg++-2.0/libg++/g++-include/sys
conform to the system include files. Once these patches are applied,
make test_h in tests will work and src/timer.cc can be compiled.

*** socket.h-orig	Fri Apr 10 16:56:49 1992
--- socket.h	Fri Apr 10 17:00:45 1992
***************
*** 20,26 ****
--- 20,30 ----
  int       select(int, void*, void*, void*, struct timeval*);
  
  int       accept(int, struct sockaddr*, int*);
+ #ifdef	NeXT
+ int       bind(int, struct sockaddr *, int);
+ #else
  int       bind(int, const void*, int);
+ #endif
  int       connect(int, struct sockaddr*, int);
  int       getsockname(int, struct sockaddr*, int*);
  int       getpeername(int, struct sockaddr*, int*);  // 16 Oct 90 Talisman
***************
*** 28,41 ****
--- 32,56 ----
  int       listen(int, int);
  int       rcmd(char**, int, const char*, const char*, const char*, int*);
  int       recv(int, void*, int, int);
+ #ifdef	NeXT
+ int       recvfrom(int, void*, int, int, struct sockaddr *, int *);
+ #else
  int       recvfrom(int, void*, int, int, void*, int *);
+ #endif
  int       recvmsg(int, struct msghdr*, int);
  int       rexec(char**, int, const char*, const char*, const char*, int*);
  int       rresvport(int*);
+ #ifdef	NeXT
+ int       send(int, void*, int, int);
+ int       sendto(int, void*, int, int, struct sockaddr *, int);
+ int       sendmsg(int, struct msghdr*, int);
+ int       setsockopt(int, int, int, void*, int);
+ #else
  int       send(int, const void*, int, int);
  int       sendto(int, const void*, int, int, const char*, int);
  int       sendmsg(int, const struct msghdr*, int);
  int       setsockopt(int, int, int, const char*, int);
+ #endif
  int       shutdown(int, int);
  int       socket(int, int, int);
  int       socketpair(int, int, int, int sv[2]);
*** wait.h-orig	Fri Apr 10 16:55:15 1992
--- wait.h	Fri Apr 10 16:56:05 1992
***************
*** 15,23 ****
--- 15,31 ----
  #define __libgxx_sys_wait_h 1
  
  struct rusage;
+ #ifdef NeXT
+ extern int wait(union wait *);
+ #else
  extern int wait(int*);
+ #endif
  extern int waitpid(int, int*, int);
+ #ifdef	NeXT
+ extern int wait3(union wait *, int options, struct rusage*);
+ #else
  extern int wait3(int*, int options, struct rusage*);
+ #endif
  extern int wait4(int, int*, int, struct rusage*);
  #endif
  }


Newsgroups: gnu.g++.lib.bug
From: allan@mct.UUCP ( System Guru)
Subject: Re: Failed test-install in libg++-2.0 if compiled with gcc-2.1
Organization: MCT Ltd., Malvern, England
Distribution: gnu
Date: Wed, 8 Apr 1992 11:15:39 GMT

I note the following comment in foo_main.cc:

/* This function should *not* be called by the environment.  There is
   no way in C++ to ``run something after the initializers but before main()''.
   The library that depends on this (NIHCL) is broken.  -- John Gilmore 
   We leave this here to test that future changes to the compiler
   do not re-introduce this losing ``feature''.  */
void 
__init_start()
{
    Foo::init_foo();
}

Does this mean that gcc and NIHCL are and will remain incomapable??

Regards,
Allan Clearwaters
MCT Ltd., 62 Albert Rd. North, Malvern, Worcs.  WR14 2TL, England
allan@mct.uucp

Newsgroups: gnu.g++.lib.bug
From: jason@jarthur.claremont.edu (Fool on a Pedestal)
Subject: Re: iostream missing operator>>(istream&,streambuf*)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 13 Apr 1992 20:36:56 GMT

>>>>> On Mon, 13 Apr 92 12:12:30 -0700, bothner@cygnus.com said:

> Try the following:

> istream& operator>>(istream& is, register streambuf* sbuf)
...

OK, now how about istream& get(streambuf&, char = '\n')?

--
Jason Merrill
jason@jarthur.claremont.edu

Newsgroups: gnu.g++.lib.bug
From: axel@thor.informatik.uni-osnabrueck.de (Axel Schreiner)
Subject: (none)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 9 Apr 1992 10:45:03 GMT

libg++-2.0 for NeXT 2.1 using gcc-2.1 configured for next

config.sub	next) set os=-mach not os=-sysv

src/timer.cc	turned off
tests/test_h.cc	does not compile
	in both cases, there are clashes between prototypes in g++-include
	and in /usr/include.

iostream/strtoul.cc
	needs to be removed or #ifdef-ed out for the NeXT,
	since strtoul() is in libsys_s.a and the loader will complain
	about duplicate definitions.

test-install/Makefile
	does not permit overwriting CC
	(not everybody has gcc in /usr/local/bin,
	 but "make CC=..." should work)

Other than that, installation appears to work.
Maybe, paths (g++-include, libg++.a) ought to be reconciled with gcc-2.1
(i.e., g++-include needs to be found implicitly.)

Newsgroups: gnu.g++.lib.bug
From: jason@jarthur.claremont.edu (Jason Merrill)
Subject: ostream << hex problem in library, not compiler
Organization: Harvey Mudd College
Distribution: gnu
Date: Sun, 12 Apr 1992 05:22:55 GMT

In an earlier posting, I complained of the errors

Arraychar.c:121: type conversion required for type `ostream'
Arraychar.c:126: type conversion required for type `ostream'

caused by the code

void THIS::printOn(ostream& strm) const
{
    strm.fill('0');
    strm.width(2);
    strm << hex;
	for (register unsigned i=0; i<sz; i++) {
		if (i > 0) strm << "  ";
 		strm << "0x" << ((unsigned int)(unsigned char)v[i]);
	}
	strm << dec;
}

and said that the problem was that g++ was not converting ostream& to ios&
correctly.  Looking at the library more closely, I realize that the problem
is not this, but rather that there is no insertor defined for type
 ios& (*)(ios&).  Diffs to iostream.h:

*** /gnu/libg++/libg++/iostream/iostream.h	Wed Feb 26 12:29:47 1992
--- g++-include/iostream.h	Sat Apr 11 22:16:20 1992
***************
*** 27,32
  class istream; class ostream;
  typedef istream& (*__imanip)(istream&);
  typedef ostream& (*__omanip)(ostream&);
  
  extern istream& ws(istream& ins);
  extern ostream& flush(ostream& outs);

--- 27,33 -----
  class istream; class ostream;
  typedef istream& (*__imanip)(istream&);
  typedef ostream& (*__omanip)(ostream&);
+ typedef ios& (*__iosmanip)(ios&);
  
  extern istream& ws(istream& ins);
  extern ostream& flush(ostream& outs);
***************
*** 77,82
  extern ostream& operator<<(ostream&, float n);
  extern ostream& operator<<(ostream&, double n);
  inline ostream& operator<<(ostream& os, __omanip func) { return (*func)(os); }
  extern ostream& operator<<(ostream&, streambuf*);
  
  class istream : public ios

--- 78,85 -----
  extern ostream& operator<<(ostream&, float n);
  extern ostream& operator<<(ostream&, double n);
  inline ostream& operator<<(ostream& os, __omanip func) { return (*func)(os); }
+ inline ostream& operator<<(ostream& os, __iosmanip func)
+ { (*func)(os); return os; }
  extern ostream& operator<<(ostream&, streambuf*);
  
  class istream : public ios
***************
*** 154,159
  extern istream& operator>>(istream&, float&);
  extern istream& operator>>(istream&, double&);
  inline istream& operator>>(istream& is, __imanip func) { return (*func)(is); }
  
  class iostream : public ios {
      _G_size_t _gcount;

--- 157,164 -----
  extern istream& operator>>(istream&, float&);
  extern istream& operator>>(istream&, double&);
  inline istream& operator>>(istream& is, __imanip func) { return (*func)(is); }
+ inline istream& operator>>(istream& is, __iosmanip func)
+ { (*func)(is); return is; }
  
  class iostream : public ios {
      _G_size_t _gcount;

Newsgroups: gnu.g++.lib.bug
From: burton@heurikon.UUCP (Kevin Burton)
Subject: libg++-2.0 linking problem (vt$filebuf)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 8 Apr 1992 19:08:32 GMT

Compiler: gcc/g++ 2.1 using gnu-coff patches for gas 1.38
OS: System Vr3
CPU: m68k

I successfully compiled libg++-2.0 after making bcopy.cc and the declaration
for libgxx_bcopy match. I now try to link test_h in the test directory and I
get:

undefined			first referenced
 symbol				    in file
__vt$filebuf			    ../libg++.a

I tracked it down to iostream in the file stdstrbufs.C and just to see if it
would make a difference I tried defining NO_DOLLAR_IN_LABEL. Then I get:

undefined			first referenced
 symbol				    in file
__vt.filebuf			    ../libg++.a

Does anyone know where this symbol is defined or should be defined ?

Thanks.


--
Kevin Burton                                mail: burton@inno.heurikon.com
Innovision Corporation                      uucp: heurikon!inno!burton
8000 Excelsior Drive Suite #304, Madison WI 53717 at&t: 608/831-4441

Newsgroups: gnu.g++.lib.bug
From: bobw@cc.usu.edu
Subject: Problems compiling libg++ on SUN 4/280
Organization: Utah State University
Distribution: gnu
Date: Thu, 9 Apr 1992 22:37:32 GMT


I have been trying to compile lib++ for our SUN 4/280 and have observed the
following problem. The makefile stops during the compile of AllocRing.c.
It seems that we have old g++ include files. Where do the proper include files
come from. Included is the log of the tail end of the make just as make libg++
begins:


(rootme=`pwd` ; export rootme ; cd src ; make prefix=/usr/local datadir=/usr/local/lib mandir=/usr/local/man against=stage2 AR=ar AR_FLAGS=qc CC=gcc XTRAFLAGS= RANLIB=ranlib LOADLIBES= LDFLAGS= BISON=bison\ -y MAKEINFO=makeinfo "CC=gcc" "XTRAFLAGS=" "AR=a
r" "RANLIB=ranlib")
gcc -I. -I./../iostream -I./../g++-include  -c AllocRing.cc
In file included from ./../g++-include/stddef.h:7, from ./../g++-include/std.h:23, from AllocRing.cc:22:
/usr/local/lib/g++-include/stddef.h:26: warning: `#pragma once' is obsolete
In file included from ./../g++-include/stdio.h:114, from ./../g++-include/std.h:28, from AllocRing.cc:22:
/usr/local/lib/g++-include/stdio.h:54: warning: `#pragma once' is obsolete
In file included from ./../g++-include/errno.h:9, from ./../g++-include/std.h:29, from AllocRing.cc:22:
/usr/local/lib/g++-include/errno.h:3: warning: `#pragma once' is obsolete
In file included from ./../g++-include/std.h:25, from AllocRing.cc:22:
./../g++-include/string.h:17: declaration of `unsigned int  strlen (const char *)'
<built-in>:0: conflicts with built-in declaration `int  strlen (const char *)'
In file included from ./../g++-include/string.h:43, from ./../g++-include/std.h:25, from AllocRing.cc:22:
./../g++-include/memory.h:12: declaration of `int  memcmp (const void *, const void *, unsigned int)'
<built-in>:0: conflicts with built-in declaration `int  memcmp (const void *, const void *, int)'
./../g++-include/memory.h:13: declaration of `void * memcpy (void *, const void *, unsigned int)'
<built-in>:0: conflicts with built-in declaration `void * memcpy (void *, const void *, int)'
make[2]: *** [AllocRing.o] Error 1
make[1]: *** [.stmp-src] Error 1
make: *** [stmp-libg++] Error 1
-- 
===============================================================================
Bob Wood    WA7MXZ                      bobw@cc.usu.edu
Utah State University                   bobw@usu.bitnet
Computer Science			tel. (801) 750-3205
UMC 4205				fax. (801) 750-3265
Logan, Utah  84322-4205
===============================================================================

Newsgroups: gnu.g++.lib.bug
From: bothner@cygnus.com
Subject: Re: libg++ and strtol
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 5 Apr 1992 15:58:42 GMT

>I compile even the simplest one line program and the loader complains
>about an undefined symbol - strtol.

strtol is required by ANSI.

>The Sequent version of Unix (bsd 4.3ish) does nor provide it

It is in NewsOS 3.2 (SOny), which is fairly straight port of 4.3bsd,
Sequent Symmetry is broken - in many ways.

>I am not using it so why is it required.

Becase it is used for I/O.

But take heart.  The next release of libg++ will include strtol.c,
and use Makefile magic to include strtol.o into libg++ if and only if
it is otherwise missing.

Until then, you can get strtol from the libiberty directory of gdb-4.x.

	--Per Bothner
Cygnus Support     bothner@cygnus.com

Newsgroups: gnu.g++.lib.bug
From: burton@heurikon.UUCP (Kevin Burton)
Subject: Building libg++ on an m68k SYSV machine
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 5 Apr 1992 22:40:34 GMT

Compiler: gcc/g++ 2.1
OS: System Vr3
CPU: m68k

I have built gcc/g++ 2.1 on our machine. There were no errors. I am
using the trick outlined by Thorsten Ohl in his "unofficial Apollo patch"
( using collect to do ld ). I installed everything then I wanted to
move on to libg++-2.0. Since our machine is not in the configuration I
changed it as outlined below and in the libg++ directory I typed `make'.
It did not work. Our system is *NOT* ANSI compliant so hence I would
expect the mismatch below. Does anyone know how I might work around it ?
I have run fixincludes. Would `-nostdinc' be an option ? When I try
that it can't find std.h as shown below. Any ideas ?


----------- Using standard makefile

burton@silver(5)$ cat config.status 
#!/bin/sh 
# This file was generated automatically by configure.  Do not edit. 
# /n/silver/usr/local/src/libg++-2.0/libg++ was configured as follows: 
/n/silver/usr/local/src/libg++-2.0/./configure hkv -target=hkv -norecursion  
#  
burton@silver(6)$ make 
        (rootme=`pwd` ; export rootme ; cd src ; \ 
                make "CC=`if [ -d ${rootme}/../gcc ] ; \ 
        then echo ${rootme}/../gcc/gcc -B${rootme}/../gcc/ ; \ 
        else echo gcc -O ; fi`" "XTRAFLAGS=`if [ -d ${rootme}/../gcc ] ; \ 
        then echo -I${rootme}/../gcc/include ; \ 
        else echo ; fi`" \ 
                "AR=`if [ -d ${rootme}/../binutils ] ; \ 
        then echo ${rootme}/../binutils/ar ; \ 
        else echo ar ; fi`" "RANLIB=`if [ -d ${rootme}/../binutils ] ; \ 
        then echo ${rootme}/../binutils/ranlib ; \ 
        else echo ranlib ; fi`") 
        gcc -O -I. -I./../iostream -I./../g++-include  -c AllocRing.cc 
In file included from ./../g++-include/std.h:28, from AllocRing.cc:22: 
./../g++-include/stdio.h:174: conflicting types for `long unsigned int  fread (void *, long unsigned int, long unsigned int, struct FILE*)' 
/usr/local/lib/gcc-lib/hkv/2.1/include/stdio.h:86: previous declaration of `int  fread (...)' 
*** Error code 1 
 
Stop. 
*** Error code 1 
 
Stop. 

----------- Using -nostdinc

        gcc -O -I. -I./../iostream -I./../g++-include -nostdinc -c AllocRing.cc 
In file included from ./../g++-include/std.h:23, from AllocRing.cc:22: 
./../g++-include/stddef.h:7: stddef.h: No such file or directory 
In file included from ./../g++-include/std.h:28, from AllocRing.cc:22: 
./../g++-include/stdio.h:114: stdio.h: No such file or directory 
In file included from ./../g++-include/std.h:29, from AllocRing.cc:22: 
./../g++-include/errno.h:9: errno.h: No such file or directory 
*** Error code 1 
 
Stop. 
*** Error code 1 
 
Stop. 


--
Kevin Burton                                mail: burton@inno.heurikon.com
Innovision Corporation                      uucp: heurikon!inno!burton
8000 Excelsior Drive Suite #304, Madison WI 53717 at&t: 608/831-4441



Newsgroups: gnu.g++.lib.bug
From: dan@uiucmath.math.uiuc.edu (Daniel R. Grayson)
Subject: constructor forgotten on vax
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 6 Apr 1992 22:22:56 GMT

On a vaxstation II under Ultrix 2.0 with gcc version 2.1:

"This is version 1.91 of libg++, the GNU C++ class library."

>From the test-install directory:

uiucmath% foo_main.run
Constructing Foo(1) "static_foo2" at 7fffdf68
Initializing Foo(2) "static_foo2" at 00001884 with Foo(1) 7fffdf68
Destructing Foo(1) "static_foo2" at 7fffdf68 (remaining foos: 1)
foo_main.cc:32: failed assertion `Foo::nb_foos() == 2'
Illegal instruction

Apparently static_foo1 is not getting constructed.  Any help would be
appreciated.

I don't know how the linker assembles calls to the initializing constructors
before main is called, so I don't know how to check up on that procedure.

Newsgroups: gnu.g++.lib.bug
From: bothner@cygnus.com
Subject: Re: libg++ link problem
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 7 Apr 1992 06:25:11 GMT

>undefined                       first referenced
> symbol                             in file
>libgxx_bcopy__FPCvPvUl              ../../libg++.a

Fix the parameter list in src/bcopy.cc to match g++-include/memory.h.

Newsgroups: gnu.g++.lib.bug
From: jason@jarthur.claremont.edu (Jason Merrill)
Subject: iostream bug and fix
Organization: Harvey Mudd College
Distribution: gnu
Date: Sat, 28 Mar 1992 20:36:49 GMT

The iostream classes in libg++ 2.0 have a bug in them when reading an EOF,
as illustrated by this program:

#include <iostream.h>
main()
{
  char buf[100];
  int i = 0;
  while( cin >> buf )
    cout << i++;
}

The program will happily read in input until EOF, then read another string,
then exit.  This is due to this chain of operation:

operator>>(istream,char*) calls istream::ipfx0()
istream::ipfx0() calls ws(istream&)
ws(istream&) calls streambuf::sbumpc()
sbumpc() calls underflow()
underflow() calls ::read()

at this point, underflow realizes that we're at EOF and sets a flag to that
effect.  So it returns EOF to ws.

ws sets ios::eofbit for cin, and returns.
ipfx0() returns happily to operator>>

operator>> calls sbumpc()
sbumpc() calls underflow()
underflow() calls ::read()
read() returns the string after the EOF
underflow() returns
sbumpc() returns the first character after the EOF
etc.

I'm not sure where the problem should be fixed.  Should ipfx0() return 1 if
the stream is at EOF?  Should sbumpc check ios::eofbit?  Or should
underflow() check its own flag?

I decided that underflow() should be responsible.  Does anyone disagree?

*** /staff/jason/oldfilebuf.C	Sat Mar 28 12:34:34 1992
--- /gnu/libg++-2.0/libg++/iostream/filebuf.C	Sat Mar 28 02:17:58 1992
***************
*** 269,274
  	return (EOF);
  #endif
  
      if ((xflags() & _S_CAN_READ) == 0) // SET ERROR
  	return EOF;
    retry:

--- 269,276 -----
  	return (EOF);
  #endif
  
+     if (xflags() & _S_EOF_SEEN) return EOF;
+ 
      if ((xflags() & _S_CAN_READ) == 0) // SET ERROR
  	return EOF;
    retry:

--
Jason Merrill
jason@jarthur.claremont.edu

Newsgroups: gnu.g++.lib.bug