45

I did a sample project to read a file into a buffer. When I use the tellg() function it gives me a larger value than the read function is actually read from the file. I think that there is a bug.

here is my code:

EDIT:

void read_file (const char* name, int *size , char*& buffer) { ifstream file; file.open(name,ios::in|ios::binary); *size = 0; if (file.is_open()) { // get length of file file.seekg(0,std::ios_base::end); int length = *size = file.tellg(); file.seekg(0,std::ios_base::beg); // allocate buffer in size of file buffer = new char[length]; // read file.read(buffer,length); cout << file.gcount() << endl; } file.close(); }

main:

void main() { int size = 0; char* buffer = NULL; read_file("File.txt",&size,buffer); for (int i = 0; i < size; i++) cout << buffer[i]; cout << endl; }
Improve this question
14
  • Is tellg() returning -1? Did you try opening the file in character mode? Commented Apr 10, 2014 at 10:11
  • tellg() returns a larger number. when i debug i see for example that i is equal to 60 and then the while loop is ending (means that we reached to eof) but tellg returns 65.. Commented Apr 10, 2014 at 10:16
  • 1
    @Sven, that link is one where the problem was text-mode instead of binary mode, but he is using binary mode here Commented Apr 10, 2014 at 12:18
  • 1
    Re. the updated code, OP, can you post the numbers you are getting? (There might be a clue...) and what does the OS say the file size is? Commented Apr 10, 2014 at 13:33
  • 1
    My answer was that your code had a compilation error, so if that was your real code you wouldn't have got so far as running it... Commented Apr 10, 2014 at 13:45

4 Answers 4

Reset to default
103

tellg does not report the size of the file, nor the offset from the beginning in bytes. It reports a token value which can later be used to seek to the same place, and nothing more. (It's not even guaranteed that you can convert the type to an integral type.)

At least according to the language specification: in practice, on Unix systems, the value returned will be the offset in bytes from the beginning of the file, and under Windows, it will be the offset from the beginning of the file for files opened in binary mode. For Windows (and most non-Unix systems), in text mode, there is no direct and immediate mapping between what tellg returns and the number of bytes you must read to get to that position. Under Windows, all you can really count on is that the value will be no less than the number of bytes you have to read (and in most real cases, won't be too much greater, although it can be up to two times more).

If it is important to know exactly how many bytes you can read, the only way of reliably doing so is by reading. You should be able to do this with something like:

#include <limits> file.ignore( std::numeric_limits<std::streamsize>::max() ); std::streamsize length = file.gcount(); file.clear(); // Since ignore will have set eof. file.seekg( 0, std::ios_base::beg );

Finally, two other remarks concerning your code:

First, the line:

*buffer = new char[length];

shouldn't compile: you have declared buffer to be a char*, so *buffer has type char, and is not a pointer. Given what you seem to be doing, you probably want to declare buffer as a char**. But a much better solution would be to declare it as a std::vector<char>& or a std::string&. (That way, you don't have to return the size as well, and you won't leak memory if there is an exception.)

Second, the loop condition at the end is wrong. If you really want to read one character at a time,

while ( file.get( buffer[i] ) ) { ++ i; }

should do the trick. A better solution would probably be to read blocks of data:

while ( file.read( buffer + i, N ) || file.gcount() != 0 ) { i += file.gcount(); }

or even:

file.read( buffer, size ); size = file.gcount();

EDIT: I just noticed a third error: if you fail to open the file, you don't tell the caller. At the very least, you should set the size to 0 (but some sort of more precise error handling is probably better).

Improve this answer
Sign up to request clarification or add additional context in comments.

14 Comments

tellg() returns a streampos object, and here it states that «Objects of this class support construction and conversion from int», so at least the statement "It's not even guaranteed that you can convert the type to an integral type" doesn't seem to be truthful.
@AndrewHenle, I stated that «the statement "It's not even guaranteed that you can convert the type to an integral type" doesn't seem to be truthful», not that «the integral value resulting from such a conversion is the size of the file», as you say.
@FabioA. C++14 27.9.1.1,p2: "The restrictions on reading and writing a sequence controlled by an object of class basic_filebuf<charT,traits> are the same as for reading and writing with the Standard C library FILEs."
(cont) C11, 7.21.9.4p2: " For a text stream, its file position indicator contains unspecified information, usable by the fseek function for returning the file position indicator for the stream to its position at the time of the ftell call; the difference between two such return values is not necessarily a meaningful measure of the number of characters written or read."
(cont) C11 7.21.9.2p3: "A binary stream need not meaningfully support fseek calls with a whence value of SEEK_END." C11, footnote 268: "Setting the file position indicator to end-of-file, as with fseek(file, 0, SEEK_END), has undefined behavior for a binary stream ..."
|
33

In C++17 there are std::filesystem file_size methods and functions, so that can streamline the whole task.

With those functions/methods there's a chance not to open a file, but read cached data (especially with the std::filesystem::directory_entry::file_size method)

Those functions also require only directory read permissions and not file read permission (as tellg() does)

Improve this answer

1 Comment

Not that these functions necessarily give the number of bytes you can read, either. At least the boost versions don't -- for the simple reason that that value isn't known, at least on some systems, until you actually read the bytes, and it depends on how you open the file (text or binary). The fact is that, at least on Windows (and doubtlessly on a lot of other systems as well), you cannot obtain the number of bytes you can read without actually reading them.
3 
void read_file (int *size, char* name,char* buffer) *buffer = new char[length];

These lines do look like a bug: you create an char array and save to buffer[0] char. Then you read a file to buffer, which is still uninitialized.

You need to pass buffer by pointer:

void read_file (int *size, char* name,char** buffer) *buffer = new char[length];

Or by reference, which is the c++ way and is less error prone:

void read_file (int *size, char* name,char*& buffer) buffer = new char[length]; ...
Improve this answer

1 Comment

yes, but still.. the problem is that tellg() returns a larger number
-3 
fseek(fptr, 0L, SEEK_END); filesz = ftell(fptr);

will do the file if file opened through fopen

using ifstream,

in.seekg(0,ifstream::end); dilesz = in.tellg();

would do similar

Improve this answer

1 Comment

On what systems? It will probably work under Unix (provided the file isn't too big), but it won't work on most other systems.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.