istream::readsome() behavior in g++ and Microsoft C++

[Alex Vinokur]

Method istream::readsome() behaves in a different way
with two different compilers: g++ and Microsoft C++.

What is reason for that?
Which compiler is correct? It seems that g++ is.

------ File xxx.cpp ------
#include <iostream>
#include <fstream>
#include <cassert>
using namespace std;

void foo()
{
char cbuffer[8];
streamsize len;

ifstream infile ("foo");
assert (infile);
assert (infile.is_open());

int i = 0;
do
{
len = infile.readsome (cbuffer, sizeof(cbuffer) - 1);
cout << "i = " << ++i << " : " << len << " " << sizeof(cbuffer) << endl;
cout << "<"; cout.write(cbuffer, len); cout << ">";
cout << "\n";
} while (len);
}

int main()
{
foo();
return 0;
}
--------------------------


------ Data file: foo ------
ABCDEFGHIK
abcdefghik
----------------------------



------ g++: Compilation & Run ------

// g++ 3.3.3

$ g++ xxx.cpp

$ a

i = 1 : 7 8
<ABCDEFG>
i = 2 : 7 8
<HIK
abc>
i = 3 : 7 8
<defghik>
i = 4 : 1 8
<i = 5 : 0 8
<>

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


------ Microsoft C++: Compilation & Run ------

// Microsoft C++ 13.00.9466

$ cl /EHcs xxx.cpp

$ xxx

i = 1 : 0 8
<>

 

[Bonj]

Most often in these "gcc does this but MSVC does this - who's right and
who's wrong" type scenarios, the answer is usually that the expected
behaviour is undefined or unspecified, but that one or the other chooses to
make some order of it anyway for convenience's sake, and that people have
assumed that it's perfectly valid to expect it to do that - which is why
well-written libraries will cause an error (hopefully compile time, but
runtime is better than nothing) if you try and write invalid code - this is
usually the case with most of the standard libraries from both gnu and ms,
but not always sadly..
You've included the code, which is good, but I think you should probably
elaborate on what it is that MSVC does wrong that g++ doesn't...

Method istream::readsome() behaves in a different way
with two different compilers: g++ and Microsoft C++.

What is reason for that?
Which compiler is correct? It seems that g++ is.

------ File xxx.cpp ------
#include <iostream>
#include <fstream>
#include <cassert>
using namespace std;

void foo()
{
char cbuffer[8];
streamsize len;

ifstream infile ("foo");
assert (infile);
assert (infile.is_open());

int i = 0;
do
{
len = infile.readsome (cbuffer, sizeof(cbuffer) - 1);
cout << "i = " << ++i << " : " << len << " " << sizeof(cbuffer) <<
endl;
cout << "<"; cout.write(cbuffer, len); cout << ">";
cout << "\n";
} while (len);
}

int main()
{
foo();
return 0;
}
--------------------------


------ Data file: foo ------
ABCDEFGHIK
abcdefghik
----------------------------



------ g++: Compilation & Run ------

// g++ 3.3.3

$ g++ xxx.cpp

$ a

i = 1 : 7 8
<ABCDEFG>
i = 2 : 7 8
<HIK
abc>
i = 3 : 7 8
<defghik>
i = 4 : 1 8
<i = 5 : 0 8
<>

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


------ Microsoft C++: Compilation & Run ------

// Microsoft C++ 13.00.9466

$ cl /EHcs xxx.cpp

$ xxx

i = 1 : 0 8
<>

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


--
Alex Vinokur
email: alex DOT vinokur AT gmail DOT com
http://mathforum.org/library/view/10978.html
http://sourceforge.net/users/alexvn

 

[Jerry Coffin]

Method istream::readsome() behaves in a different way
with two different compilers: g++ and Microsoft C++.

readsome is allowed to be mostly a nop -- other than things like
correctly setting the failbit, it isn't required to do much of
anything. In particular, it only reads characters if in_avail says
there are characters available at the moment. in_avail, in turn, uses
showmanyc to find out how many characters are in the stream buffer --
and showmanyc is allowed to return 0 (in fact, that's its default
behavior).

In this case, it _looks_ like gcc fills the buffer from the file (or
attempts to) when you open the file but MS delays doing any actual
reading until you request a read from the file.

I don't see anything in the standard requiring one or the other. I'd
consider it a judgement call which is better, but I don't how it would
affect conformance with the standard.