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

A

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
<>
 
B

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...


Alex Vinokur said:
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
 
J

Jerry Coffin

Alex said:
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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,902
Latest member
Elena68X5

Latest Threads

Top