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

[Per W. <pw...@ia...>]

You don't show what type value has, but if it's signed, your in for a bit
of surprise if you try and shift and mask on it.

Most compilers - not all as Ioannis and I have had an earlier discussion
about yesterday :-) - will shift in most significant bit set if you shift
a negative value to the right.

Note that 0xbd is the same is 189 unsigned or -67 signed.

/Per W

On Thu, 6 Mar 2003, "J=F6rgen" wrote:

> Hi.
>
> This problem puzzles me. I have the following data.
> -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 4 7 0 4 8 0 4 9 0 3 9 27 1 10 27 2 10 36 1 10 54 1 11 108 1 11 189 1
>
> I'm not to familiar with reg.exp, but I guess that the reg.exp. for the d=
ata would be
> result [value1 value2 value3]*
>
> where
>   result is an integer but is always in the range -64 to 64
>   value1 is an integer but is always in the range 0 to 11
>   value2 is an integer but is always in the range 0 to 65536
>   value3 is an integer but is always in the range 0 to 4
>
> let's say that we call [value1 value2 value3] for 'value' and 'nbrOfValue=
s' the number of sets of 'value'. In this case nbrOfvalues =3D 20
>
> When I write the data to file, using ofstream foo("foofile") I do it in t=
he following way
>
> if(result < 0)
>   foo << '-';
> else
>   foo << '+';
> foo << ((unsigned char) (abs(result) & 0x000000FF));
>
> for(int i=3D0; i<numberOfValues; i++){
>   foo << ((unsigned char) (value[i][0] & 0x000000FF));
>   foo << ((unsigned char) ((value[i][1] & 0x0000FF00) >> 8));
>   foo << ((unsigned char) (value[i][1] & 0x000000FF));
>   foo << ((unsigned char) (value[i][2] & 0x000000FF));
> }
>
> The problem comes when I read the data from file. If I just reverse the p=
rocedure and prints the decoded data to screen I get
> -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 4 7 0 4 8 0 4 9 0 3 9 27 1 10 27 2 10 36 1 10 54 1 11 108 1 11 189 1 0 8=
0 114
>
> It looks just the same as the original data except for the last three num=
bers (0 80 114).
>
> When looking at the filesize it shows that it is 85 bytes, but the data w=
ritten is only 82 bytes
>
> For debugging purposes, instead of writing directly to file, I first stor=
e everything in a string s. That is, replacing foo << ... with s +=3D ... F=
inally I write it to file with foo << s;
>
> When I print the string s to screen in hex-mode
>
> cout.setf( ios_base::hex, ios_base::basefield );
> for(int i=3D0; i<s.size(); i++)
>   cout << " " << s[i];
>
> it gives the following output
> 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 0 0 8 5 0 0 4 6 0 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 0 bd 1
> and it is the way it should be
>
> But when I look at the datafile in a hexeditor I see
> 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 0 0 8 5 0 0 4 6 0 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 1 b 0 bd 1
>
> An extra byte 'd' emerges before every one of the three "value1"-'a' byte=
s (d a 0 1b 2 , d a 0 24 1 , d a 0 36 1).
>
> Where did these 'd' bytes come from?
> Why are the only occuring in front of the 'a' byte?
> How come that when I print the data to screen it does not mess up the val=
ues but instead appends (0 80 114) at the end?
> Finally, and most important, how do I get rid of them?
>
>
> Any ideas are very welcome.
>
> TIA
> /J=F6rgen
>
>