Hi guys, first of all let me say that I'm a Delphi guys, but I've been cleaning up some old legacy C++ code without any real issues.

The following piece of code however baffles me!

It looks like it simply copies the binary input file to another file bit by bit, and does some funky bitwise stuff with int1 and int2, again for reasons unknown.

What also confuses me i.e. if I try write the output of the integers I get some funky results i.e.
fprintf(fTestFile, "%d\n", int2);
This gives me numbers in the 100s of thousands, which I would have thought out of the scope of a single char (this variable was originally a byte but MS VCpp would not compile the code.)

Anyone know what purpose it may all serve and why the bytes are going into the 1000s?

Major thanks in advance.

Joe.

bool ForLINUX, ForDOS;
char bWriteByte;
int	iDataArray[1500];
int iCount, iOutFileH, int1, int2;
FILE *fInData, *fOutData, *fTestFile;

	ForLINUX = false;
	ForDOS = true;

	fInData = fopen("\\Almeter\\baseline.dta", "rb");
	fOutData = fopen("\\Almeter\\OutData.bin", "wb+");	
	iOutFileH = fileno(fOutData);

	iCount = 0;
	while(fread( &int1, 1,1, fInData) == 1)  {

		bWriteByte = int1;
		if (ForLINUX) write(iOutFileH, &bWriteByte, 1);      
		if (ForDOS) _write(iOutFileH, &bWriteByte, 1);

		int1 = (int1 << 8) & 0xff00;
		if (!fread(&int2, 1,1, fInData)) exit(0);
		int1 |= (int2 & 0xff);
		iDataArray[iCount++] = int1;

		bWriteByte = int2;
		if (ForLINUX) write(iOutFileH, &bWriteByte, 1);
		if (ForDOS) _write(iOutFileH, &bWriteByte, 1);
	}
	fclose(fInData);
	fclose(fOutData);

Edited 6 Years Ago by WaltP: Added CODE tags -- with all the help about them, how could you miss using them????

variable int1 is an integer (4-bytes on a 32-bit compiler), not a char. So the fread() will just read garbage into it. Or you might change that line to this: while( fread( &int1, 1, sizeof(int1)) > 0 )

> bool ForLINUX, ForDOS;
> iOutFileH = fileno(fOutData);
> if (ForLINUX) write(iOutFileH, &bWriteByte, 1);
> if (ForDOS) _write(iOutFileH, &bWriteByte, 1);
All this 'for...' nonsense is a load of rubbish.
fread() is used to read the file, so use fwrite() to write to the file.

As an attempt to make the code portable, it SUCKS.

> This gives me numbers in the 100s of thousands, which I would have thought out of the scope of a single char
A single byte typically represents a small integer from 0 to 255 inclusive.

> iDataArray[iCount++] = int1;
Unless your files are really small, this array will rapidly over-run and trashing other memory locations will begin.

Further to what AD already mentioned (about uninitialised data), there is also an endian problem.
If you imagine a 4-byte integer stored as AABBCCDD, then on some machines the fread will overwrite DD and the bit-fiddling code makes sense. On other machines, AA will be overwritten by the fread, and the bit-fiddling code is manipulating garbage.

Hi guys - first of all - major thanks to everyone for your comments and speedy response.

So, just to clarify:

1. The code reads a single byte into a 4-byte integer leaving 3 bytes full of garbage.

2. The integer is copied into a char (what I believe was once a byte).
Copying the correct (HO/LO) byte from the integer?

3. It then shifts the first 8 bits left 8 places while using "& 0xff00" to clean out to empty the first byte and clean out any cr@p from the second byte - still leaving 2 bytes of garbage.

I'm beginning to think this was perhaps written in an old version of C++ an "integer" type was 16-bit..

4. A following byte is read into a second integer, and the bits written to the right (High End?) byte using "int1 |= (int2 & 0xff)".

i.e. in your opinion, is the whole purpose to do the following?

short sInt;

while(fread( &sInt, 1,2, fInData)) {
     iDataArray[iCount++] = sInt;
     fwrite(&sInt, 1, 2, fOutData);
}

Also, any ideas why, in it's current state the code would seem to write an extra byte (255) to "Outfile" about 18 bytes in? (wild stab in the dark here :D).

Major thanks again.

Joe.

Edited 6 Years Ago by BazookaJo: n/a

This article has been dead for over six months. Start a new discussion instead.