problem when reading from large binary file

[WiKiDJeFF]

do you see anything wrong this this code. sSend is a class that encapsulates the winsock API.

ifstream openfile((const char *)FileName.c_str(),ios::in | ios::binary);
	char tmpContent[10000] = {0};
	int left = 0;
	


	if(openfile.is_open())
	{
		//int length = openfile.tellg();

		while(!openfile.eof())
		{
			left = GetFileLen((char *)FileName.c_str()) - openfile.gcount();

			if(left < 2048)
			{
				openfile.read(tmpContent, left);
			}
			else
			{
				openfile.read(tmpContent, 2048);
			}

			

			//openfile.read(tmpContent, left);
			
			sSend.SendData(tmpContent);

			
		}

		sSend.Close();
	}

int GetFileLen(char *path)
{
	ifstream TheFile((const char *)path, ios::in | ios::ate | ios::binary);

	return TheFile.tellg();
}

[CornedBee]

You may get problems with file locking. Usually ifstream will lock the file so that it can't be opened another time.

Why do you recalculate the file size every iteration? Calculate it once and be done with it.

Why do you cast the return of c_str? It's already of type const char * and every useless cast is dangerous as it might occlude real errors.

Why is the buffer 10000 bytes large when you never read more than 2048 bytes?

[WiKiDJeFF]

ok i fixed the things u said the function now looks like this:

ifstream openfile(FileName.c_str(),ios::in | ios::binary);
	char tmpContent[2048] = {0};
	int left = 0;
	int size = GetFileLen((char *)FileName.c_str());
	


	if(openfile.is_open())
	{
		//int length = openfile.tellg();

		while(!openfile.eof())
		{
			left = size - openfile.gcount();

			if(left < 2048)
			{
				openfile.read(tmpContent, left);
			}
			else
			{
				openfile.read(tmpContent, 2048);
			}

			

			//openfile.read(tmpContent, left);
			
			sSend.SendData(tmpContent);

			
		}

		sSend.Close();
	}

[CornedBee]

Looks ok. Does it work?

[WiKiDJeFF]

unfortunately no, it worked fine for a small text file with about 15 characters in it. But then i tried it on a 24KB executable and it didn't work. It sent the first line of code correctly, but after that it just sent a couple long lines of weird looking ÿ's along with some other weird characters. The final file was only 4KB instead of 24KB. I have no clue why. It shouldn't matter whether tmpContent is a char or unsigned char right?

[WiKiDJeFF]

by the way this function is a member of a class and takes place inside a thread.

[CornedBee]

You open it binary, is it supposed to contain printable data?

[WiKiDJeFF]

no, but I opened its output in notepad.

[CornedBee]

Then it's no surprise it's strange characters. So the only strange thing is that it doesn't copy the full amount of data. Hav you tried doing a debug run?

[WiKiDJeFF]

it is a suprise that its strange characters since it is different strange characters then the original exe. I havent tried a debug run, but I did put a MessageBox before the part where I send the data and it shows the same strange characters that end up in the output file.

[nabeels786]

try

char *tmpContent = new char[2048];

strcpy(tmpContent, " ");


Maybe the memory it allocated has garbage in it, and if its less than 2048, itll fill whatever amount, but leave the rest with garbage, that happens to me sometimes

[WiKiDJeFF]

the code is now this and it produces the same result with the same problem:

ifstream openfile(FileName.c_str(),ios::in | ios::binary);
	char *tmpContent = new char[2048];
	strcpy(tmpContent, " ");

	int left = 0;
	int size = GetFileLen((char *)FileName.c_str()) + 1;

	if(openfile.is_open())
	{

		while(!openfile.eof())
		{
			left = size - openfile.gcount();

			if(left < 2048)
			{
				openfile.read(tmpContent, left);
			}
			else
			{
				openfile.read(tmpContent, 2048);
			}

			MessageBox(NULL,tmpContent, "tmpContent", MB_OK);
			
			sSend.SendData(tmpContent);
		}

		sSend.Close();
	}

[parksie]

Your "SendData" function -- how does it know how big the data block is?

Also, I'd recommend using memset() rather than strcpy() -- set all of tmpContent to 0 first.

[WiKiDJeFF]

The code now looks like this and produces the same result with the same problem, I have commented the SendData function in case it was creating any problems.

	ifstream openfile(FileName.c_str(),ios::in | ios::binary);
	char *tmpContent = new char[2048];
	memset(tmpContent, 0, 2048);
	int left = 0;
	int size = GetFileLen((char *)FileName.c_str()) + 1;

	if(openfile.is_open())
	{

		while(!openfile.eof())
		{
			left = size - openfile.gcount();

			if(left < 2048)
			{
				openfile.read(tmpContent, left);
			}
			else
			{
				openfile.read(tmpContent, 2048);
			}

			MessageBox(NULL,tmpContent, "tmpContent", MB_OK);
			
			//sSend.SendData(tmpContent);
		}

		sSend.Close();
	}

[parksie]

You can't display binary data, remember.

[WiKiDJeFF]

when u say display, do u mean MessageBox()?

[WiKiDJeFF]

ok i just made a big improvement. I fixed the SendData function so it works properly and i fixed a couple other things. Now the output file looks very similiar to the original file. They are both 24.0 KB in Size, but the output file is 28.0 size on disk (according to properties). What is the difference between size and size on disk? Also when I open up the original file and the output file in notepad they seem to have the same content, except in slightly different places. And all the weird characters are different in each file. Would it matter that im using char and not unsigned char?

[Arawn]

Size on disk just means how much physical space it's taking. Your hard drive is divided into clusters, that are usually 8k big. Even a 1k file will take up 8k of space on your drive.

[WiKiDJeFF]

So how could two files be the same size but different sizes on disk?

[CornedBee]

It could be more fragmented.

The cluster size is not always the same, it's dependent on the disk and on the file system.

[WiKiDJeFF]

Is there any reason why it would be screwing up the binary characters? are you sure it doenst need to be an unsigned char?

[Arawn]

Perhaps the problem is in the function that receives it?

[Chris]

Hi, CornedBee, how "every useless cast is dangerous as it might occlude real errors"? Just wondering to know. As it might occur in my daily code

[CornedBee]

Test Arawn's idea by directly writing to another file, then comparing those.

Chris: The compiler disallows some implicit casts because it can't know if it makes sense, e.g. casting a base class pointer to a derived class pointer. Since the compiler can't know if the base class pointer really points to a derived object, and because it would cause huge problems if it didn't you have to explicitly cast the pointer, either with reinterpret_cast, dynamic_cast or C-style cast. Getting into the habit of explicitly casting everything that produces problems could for example lead to the following problems:
1)

void func(int *some_val)
{
  // lots and lots of code
  int i = some_val;
}

This creates a compiler casting error. Without really looking you just add the explicit cast.

void func(int *some_val)
{
  // lots and lots of code
  int i = (int)some_val;
}

Bingo, you are *****ed.
2)

#include <string>
using std::string;

string s("Hello there");
// dumdidum
// cast, else compiler error
char * cs = (char *)s.c_str();

If you now modify cs you have problems again. Casting away const is never good and means that something with your code design is wrong. The const modifier is really great.

[parksie]

Originally posted by CornedBee

#include <string>
using std::string;

string s("Hello there");
// dumdidum
// cast, else compiler error
char * cs = (char *)s.c_str();

If you now modify cs you have problems again. Casting away const is never good and means that something with your code design is wrong. The const modifier is really great.

I don't think you're allowed that last one, I thought you needed const_cast It might have changed though.

[CornedBee]

You were allowed in C, because there was no const_cast, and I don't think they anyhow reduced the abilities of the C-style cast.

[parksie]

There wasn't originally a const in C, though.

Just testing....

[parksie]

You're right.

#include <iostream>

void yarr(const int *blah) {
    int* hmmm = (int*)blah;
    *hmmm = 5;
}

int main() {
    int weebl;
    
    cout << weebl << endl;
    
    yarr(&weebl);
    
    cout << weebl << endl;
}

That compiles fine (and works, at least on this one...).

[CornedBee]

yarr(&weebl);

LOLOLOLOL !!!!!

[parksie]

Thought I'd add some insanity to the situation

[WiKiDJeFF]

lol ok i figured out why it wasnt working. You were right the problem was on the receiving end. The program that was receiving it was made in VB and when I checked the source I found that it wasn't writing to the file in binary mode. I fixed that and now it seems to be working fine.

[WiKiDJeFF]

P.S. thx for all ur help