On torsdag, oktober 3, 2002, at 04:41 , Justin C. Walker wrote:
> > On Wednesday, October 2, 2002, at 01:40 PM, Per Persson wrote: > >> Hi, >> since I've gotten prompt and correct information here before, here >> goes again: >> >> In porting octave I've come across a problem with iostream. Reading >> from a file of binary data, the last byte gets lost. It seems that the >> stream is invalidated when reading up to EOF rather than actually >> reading EOF. >> Running the code snippet below will show what I mean (the file bindata >> contains "foo-i-hithere\n", 14 chars): > > The behavior of gcc 2.95.2 and gcc 3.1 (1151) [on 10.1.5] is different; > 2.95.2 reads 14 bytes; 3.1 reads 13. Perhaps there is a change in the > default "flags" for the standard streams? > > FWIW, Bjarne tells me that the default for '>>' is to skip whitespace > (which includes '\n'), but I don't know whether that applies to > specific streams (e.g., stdin; ttys), or in general. > > He also tells me that > > is.unsetf(ios_base::skipws); > > will instruct the stream to not skip whitespace, which does *not* seem > to be the case. > > This could be a case of incomplete C++ STL stuff for GCC (but since I > don't know C++, I'm just flailing). Thanks, but whitespace or not doesn't matter. It is definitely a difference between platforms in terms of behaviour. Now, I haven't found out what the standard says about stream states, but since the stream instance is 0 after reading the last byte the question is whether I can trust is.eof() and is.good() at that point... BTW, gcc is 1161 on OS X 10.2.1 /Per
