Thu Oct 04 02:32:27 1990
John M. Dlugosz
Dlugosz Software
PO Box 867506
Plano TX, 75086
(214)985-8098


I have made several fixes to Borland's IOSTREAM library, as detailed
below.  This was just my first go at it, and I intent to persue the
project.  A donation of $5 would be greatly appreciated, and would
help insure that I continue to apply the time and effort to going over
Borland's code.

Feel free to bring any additional bugs, problems, or questions concerning
the library to my attention.  I can be reached at the above address, or
on BPROGB on CompuServe.

There are replacement OBJ's included.  You should unzip with -d or extract
individual files only, since they have the same names but are in different
subdirectories.  You can link in these files explicitly in you project
to try them out without updating your LIBs.

Note:  this file is not from Borland and is not an official patch.  If you
have any questions or problems or requests, you need to contact me personally
and not Borland Technical Support.




  A couple of questions posted on c.plus.plus for further research
  ----------------------------------------------------------------

(1) setf(b)

The docs state that ios::setf(long) will
"turn on the format flags marked in b and returns the previous settings."

Looking at TC++'s library, I see what it
really does is:

long ios::setf (long b)
{
long retval= flags & l;
flags |= b;
return retval;
}

That is, instead of returning the old unmodified
flags, it only returns those flags that are being
modified.  Is that right?  Somehow I don't think so.


(2) endl manipulator

Is the meaning of o << endl exactly the same as the
meaning of o << '\n' << flush; ?  Specifically, that
uses a formatted inserter which will use and reset width.
Or should it insert the '\n' without affecting the width?
Consider  o << setw(5) << endl << 'x';   Will that cause the
end of line to be justified, or will the setw stick around to
be applied to the 'x'?  Personally, I think that endl should
reset the width since it appears as the thing following the
setw and that keeps things consistant.  But I don't know if
it should actually use the width or throw it away.


Notes on changes

----------------------------------------------------------------

the inline functions ipfx0() and ipfx1() apperently avoid the call to
ipfx() if it does not need to actually do anything.  However, it does
not reset _gcount if the call is skipped.  Is this an error?

------------------

All extractors, formatted and unformatted, should set failbit if an
attempt was made to read at EOF.  This would be an else clause to the
ipfx() call.  It seems to be missing everywhere.  How about just
putting it in ifpx()?      Nope, peek() calls the prefix function too
and I don't think that sets the error. (check on this).  One form of
getting a character does not set failbit either.  Oh well, I'll stick
the `else' on all the extractors:

** the only unformatted extractors that do not set failbit are
      get() (no arg form)  and (my feeling here) peek().

from ISTREAMI.CPP
    istream& istream::operator>> (long& l)
from ISTREAMN.CPP
    istream& istream::operator>> (signed char* p)
        (fixed "always add terminating '\0' while I'm here)
    istream& istream::operator>> (streambuf* s)
        (not the BIG_INLINE version on the following ones, just the
         linked in one)
    istream& istream::operator>> (unsigned char& c)
    istream& istream::operator>> (signed char& c)

I don't understand why istream& istream::get(char& c)
will proceed to call do_get() (which does in deed to stuff) if
ipfx() returns failure.  This means that a character will be read
from the buffer, if available, even if the stream's state is an
error.  I beleive this is wrong.

Furthermore, I don't think get(c) should modify c if the stream is not
good.  The docs are quite clear that "call ipfx(1) and proceed only
if it returns non-zero."  exceptions, like get(char*) always nul-terminating,
(which Borland got wrong, BTW) are clearly stated, so it is clear that in
general the argument is not stuffed in the error case.

I have not modified get(char&) functions.  I will wait until I get more
input on the correct behavor.

------------

The next problem to address is getline().  It incorrectly stores the
delimiter character in the buffer.

-----------

Ostreams-- 

the char inserter does not respect the format flags.  `width' is niether
acted on or reset.  That is fixed (file OSTREAMN.CPP)



