🚀 go-pugleaf

   Date: 7 Oct 89 02:56:04 GMT
   From: eklee@ernie.berkeley.edu  (Edward K. Lee)
   Organization: University of California, Berkeley
   Sender: bug-lib-g++-request@prep.ai.mit.edu

   In function 'int Filebuf::underflow()' of file streambuff.cc, the first
   assignment to 'eptr' which reads:

       eptr = base + Fp->fp->_bufsize;

   should be:

       eptr = base + Fp->fp->_cnt+1;

Your fix is wrong for `standard' unix stdio's. The eptr should be
pointing to one past the end of the buffer, not to the fill point.

   The supplied test programs tended to hang before I made this change.

   Misc. Questions/Comments:
   Is it really necessary to directly access the members of the FILE structure?
   (I'm running on Sprite which uses a different FILE structure than unix,
   requiring me to manually change all such references.)

No it's not. You CAN use `filebuf's, which make many fewer assumptions
about things, but are implemented in a less powerful/flexible way
(avoiding stdio FILE's completely) that makes ANY simultaneous use of
stream operations and C stdio (like printf) a bad idea. (With
Filebuf's, they can be intermixed to some minimal, but usually
acceptable, extent, although you should normally use flush when doing
so for output.) filebufs are also a little more cumbersome to use. But
if you need to use them, it's easy to modify accordingly.  Mostly you
need to have the 3 predefined global streams use filebufs, not
Filebufs: At the bottom of src/stream.cc, replace

---

ostream  cerr(stderr);
ostream  cout(stdout);
istream  cin(stdin, 1, &cout);

whitespace WS;

---
    with 
---
#ifndef DEFAULT_filebuf

ostream  cerr(stderr);
ostream  cout(stdout);
istream  cin(stdin, 1, &cout);

#else

static char cerrbuf[1];
static char coutbuf[BUFSIZE];
static char cinbuf[BUFSIZE];

ostream cerr(2, cerrbuf, 1);
ostream cout(1, coutbuf, BUFSIZE);
istream cin (0, cinbuf,  BUFSIZE, 1, &cout);

#endif

whitespace WS;

---

and then add -DDEFAULT_filebuf to your compilation flags.
I will put something to this effect in the next release.

   Has anyone gotten gdb 3.2 to run properly?
   In particular, I can't get 'info method' to work at all.

Apparently these will behave better under the next releases of
g++ and gdb.

   Ed

-Doug