Re: [Dev-C++] Some extra bytes written to file?

[Ioannis V. <no...@ho...>]

Important correction:=0D
=0D
=0D
 -------Original Message-------=0D
 =0D
From: Ioannis Vranos=0D
Date: =D0=DD=EC=F0=F4=E7, 6 =CC=DC=F1=F4=E9=EF=F2 2003 11:37:40 =EC=EC=0D
To: Dev-C++ Mailing List=0D
Subject: Re: [Dev-C++] Some extra bytes written to file?=0D
 =0D
-------Original Message------- =0D
=0D
From: "J=F6rgen" =0D
Date: =D0=DD=EC=F0=F4=E7, 6 =CC=DC=F1=F4=E9=EF=F2 2003 5:00:15 =EC=EC =0D
To: dev...@li... =0D
Subject: [Dev-C++] Some extra bytes written to file? =0D
=0D
Hi. =0D
=0D
This problem puzzles me. I have the following data. =0D
-4 0 0 4 1 0 4 2 0 3 2 27 1 3 108 1 3 135 1 3 189 1 3 351 1 4 0 8 5 0 4 6=
 0=0D
4 7 0 4 8 0 4 9 =0D
0 3 9 27 1 10 27 2 10 36 1 10 54 1 11 108 1 11 189 1 =0D
=0D
I'm not to familiar with reg.exp, but I guess that the reg.exp. for the d=
ata=0D
would be =0D
result [value1 value2 value3]* =0D
=0D
where =0D
result is an integer but is always in the range -64 to 64 =0D
value1 is an integer but is always in the range 0 to 11 =0D
value2 is an integer but is always in the range 0 to 65536 =0D
value3 is an integer but is always in the range 0 to 4 =0D
=0D
let's say that we call [value1 value2 value3] for 'value' and 'nbrOfValue=
s'=0D
the number of sets =0D
of 'value'. In this case nbrOfvalues =3D 20 =0D
=0D
When I write the data to file, using ofstream foo("foofile") I do it in t=
he=0D
following way =0D
=0D
=0D
=3D=3D> Since it is C++, why don't you use bitset<> elegantly and efficie=
ntly? =0D
=0D
=0D
=0D
if(result < 0) =0D
foo << '-'; =0D
else =0D
foo << '+'; =0D
foo << ((unsigned char) (abs(result) & 0x000000FF)); =0D
=0D
for(int i=3D0; i<numberOfValues; i++){ =0D
foo << ((unsigned char) (value[i][0] & 0x000000FF)); =0D
foo << ((unsigned char) ((value[i][1] & 0x0000FF00) >> 8)); =0D
foo << ((unsigned char) (value[i][1] & 0x000000FF)); =0D
foo << ((unsigned char) (value[i][2] & 0x000000FF)); =0D
=0D
=0D
=3D=3D> CORRECTION: Since value2 is [0,65536] use unsigned long. E.g. =0D
=0D
for(int i=3D0; i<numberOfValues; i++){ =0D
foo << static_cast<unsigned long> (value[i][0]) & 0x000000FF; =0D
foo << static_cast<unsigned long>(value[i][1]) & 0x0000FF00 >> 8; =0D
foo << static_cast<unsigned long> (value[i][1]) & 0x000000FF; =0D
foo << static_cast<unsigned long> (value[i][2]) & 0x000000FF; =0D
=0D
=0D
=3D=3D>CORRECTION: The casting should be applied "before" the bitwise ope=
ration.=0D
=0D
=0D
=0D
=0D
} =0D
=0D
The problem comes when I read the data from file. If I just reverse the=0D
procedure and prints =0D
the decoded data to screen I get =0D
-4 0 0 4 1 0 4 2 0 3 2 27 1 3 108 1 3 135 1 3 189 1 3 351 1 4 0 8 5 0 4 6=
 0=0D
4 7 0 4 8 0 4 9 0 =0D
3 9 27 1 10 27 2 10 36 1 10 54 1 11 108 1 11 189 1 0 80 114 =0D
=0D
It looks just the same as the original data except for the last three=0D
numbers (0 80 114). =0D
=0D
When looking at the filesize it shows that it is 85 bytes, but the data=0D
written is only 82 bytes =0D
=0D
For debugging purposes, instead of writing directly to file, I first stor=
e=0D
everything in a =0D
string s. That is, replacing foo << ... with s +=3D ... Finally I write i=
t to=0D
file with foo << s; =0D
=0D
When I print the string s to screen in hex-mode =0D
=0D
cout.setf( ios_base::hex, ios_base::basefield ); =0D
for(int i=3D0; i<s.size(); i++) =0D
cout << " " << s[i]; =0D
=0D
it gives the following output =0D
2d 4 0 0 0 4 1 0 0 4 2 0 0 3 2 0 1b 1 3 0 6c 1 3 0 87 1 3 0 bd 1 3 1 5f 1=
 4=0D
0 0 8 5 0 0 4 6 0 =0D
0 4 7 0 0 4 8 0 0 4 9 0 0 3 9 0 1b 1 a 0 1b 2 a 0 24 1 a 0 36 1 b 0 6c 1 =
b=0D
0 bd 1 =0D
and it is the way it should be =0D
=0D
But when I look at the datafile in a hexeditor I see =0D
2d 4 0 0 0 4 1 0 0 4 2 0 0 3 2 0 1b 1 3 0 6c 1 3 0 87 1 3 0 bd 1 3 1 5f 1=
 4=0D
0 0 8 5 0 0 4 6 0 =0D
0 4 7 0 0 4 8 0 0 4 9 0 0 3 9 0 1b 1 d a 0 1b 2 d a 0 24 1 d a 0 36 1 b 0=
 6c=0D
1 b 0 bd 1 =0D
=0D
An extra byte 'd' emerges before every one of the three "value1"-'a' byte=
s =0D
(d a 0 1b 2 , d a 0 24 1 , d a 0 36 1). =0D
=0D
Where did these 'd' bytes come from? =0D
=0D
=0D
=3D=3D> Truncation. You "bitwise" a signed value (casted to unsigned type=
) and=0D
its bit, marking its signess floats around. Also keep in mind that the=0D
binary representation of negative values is radically different from the=0D
positive ones. =0D
=0D
=0D
Why are the only occuring in front of the 'a' byte? =0D
How come that when I print the data to screen it does not mess up the val=
ues=0D
but instead =0D
appends (0 80 114) at the end? =0D
=0D
=0D
=3D=3D> Hmmm. =0D
=0D
=0D
=0D
Ioannis Vranos =0D
=0D
* Programming pages: http://www.noicys.freeurl.com =0D
* Alternative URL: http://run.to/noicys=20