Thread: [Dev-C++] Some extra bytes written to file?
Open Source C & C++ IDE for Windows
Brought to you by:
claplace
Menu
▾
▴
dev-cpp-users
|
From: <qa...@ho...> - 2003-03-06 14:57:05
|
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=
data 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 'nbrOfValues'=
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 the=
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=
procedure 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 80=
114
It looks just the same as the original data except for the last three=
numbers (0 80 114).
When looking at the filesize it shows that it is 85 bytes, but the data=
written is only 82 bytes
For debugging purposes, instead of writing directly to file, I first store=
everything in a string s. That is, replacing foo << ... with s +=3D ...=
Finally 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' bytes=
(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=
values 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
|
|
From: Per W. <pw...@ia...> - 2003-03-06 15:52:40
|
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
>
>
|
|
From: <qa...@ho...> - 2003-03-06 16:42:04
|
Hi,
The type is signed, but as you can see there are no negative values=
[0...11, 0...65536, 0...4], so that shouldn't be the problem because the=
most significant bit is zero. I've tried every possible combination I can=
think of but I can't not figure out where the extra bytes comes from.
/J=F6rgen
*********** REPLY SEPARATOR ***********
On 2003-03-06 at 16:51 Per Westermark wrote:
>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
>data 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
>'nbrOfValues' 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
>the 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
>procedure 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
>80 114
>>
>> It looks just the same as the original data except for the last three
>numbers (0 80 114).
>>
>> When looking at the filesize it shows that it is 85 bytes, but the data
>written is only 82 bytes
>>
>> For debugging purposes, instead of writing directly to file, I first
>store everything in a string s. That is, replacing foo << ... with s +=3D
>... Finally 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'
>bytes (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
>values 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
>>
>>
|
|
From: Per W. <pw...@ia...> - 2003-03-06 18:42:06
|
If you are using signed variables, you should be careful about
larger than 127 for char
larger than 32767 for int
larger than 2147483647 for long
or you will set the sign bit. If a small signed variable is type-converted
to a larget signed variable, it will be sign-extended, i.e. all "new" bits
of the larger integer will be set to 1.
/Per W
On Thu, 6 Mar 2003, "J=F6rgen" wrote:
> Hi,
>
> The type is signed, but as you can see there are no negative values [0...=
11, 0...65536, 0...4], so that shouldn't be the problem because the most si=
gnificant bit is zero. I've tried every possible combination I can think of=
but I can't not figure out where the extra bytes comes from.
>
> /J=F6rgen
>
> *********** REPLY SEPARATOR ***********
>
> On 2003-03-06 at 16:51 Per Westermark wrote:
>
> >You don't show what type value has, but if it's signed, your in for a bi=
t
> >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 shif=
t
> >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 th=
e
> >data 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
> >'nbrOfValues' 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 i=
n
> >the 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 th=
e
> >procedure 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
> >80 114
> >>
> >> It looks just the same as the original data except for the last three
> >numbers (0 80 114).
> >>
> >> When looking at the filesize it shows that it is 85 bytes, but the dat=
a
> >written is only 82 bytes
> >>
> >> For debugging purposes, instead of writing directly to file, I first
> >store everything in a string s. That is, replacing foo << ... with s +=
=3D
> >... Finally 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 5=
f
> >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 5=
f
> >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'
> >bytes (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
> >values 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
> >>
> >>
>
>
>
>
|
|
From: Ioannis V. <no...@ho...> - 2003-03-06 21:39:41
|
-------Original Message-------=0D =0D From: "J=F6rgen"=0D Date: =D0=DD=EC=F0=F4=E7, 6 =CC=DC=F1=F4=E9=EF=F2 2003 6:44:34 =EC=EC=0D To: Per Westermark=0D Cc: dev...@li...=0D Subject: Re: [Dev-C++] Some extra bytes written to file?=0D =0D Hi,=0D =0D The type is signed, but as you can see there are no negative values [0...= 11, 0...65536, 0...4], so that shouldn't be the problem because the most significant bit is zero. I've tried every possible combination I can thin= k of but I can't not figure out where the extra bytes comes from.=0D =0D =0D =3D=3D> Strictly speaking you do not know how the implementation implemen= ts signed types. It is only guaranteed to work with unsigned ones.=0D =0D =0D =0D Ioannis Vranos=0D =0D * Programming pages: http://www.noicys.freeurl.com=0D * Alternative URL: http://run.to/noicys=20 |
|
From: <qa...@ho...> - 2003-03-06 18:24:50
|
Hi again.
Found the solution to my problem. If I write the file as a binaryfile it=
works perfect.
I don't understand why I have to do that though.
/J=F6rgen
*********** REPLY SEPARATOR ***********
On 2003-03-06 at 16:51 Per Westermark wrote:
>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
>data 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
>'nbrOfValues' 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
>the 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
>procedure 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
>80 114
>>
>> It looks just the same as the original data except for the last three
>numbers (0 80 114).
>>
>> When looking at the filesize it shows that it is 85 bytes, but the data
>written is only 82 bytes
>>
>> For debugging purposes, instead of writing directly to file, I first
>store everything in a string s. That is, replacing foo << ... with s +=3D
>... Finally 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'
>bytes (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
>values 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
>>
>>
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: Etnus, makers of TotalView, The
>debugger
>for complex code. Debugging C/C++ programs can leave you feeling lost and
>disoriented. TotalView can help you find your way. Available on major UNIX=
>and Linux platforms. Try it free. www.etnus.com
>_______________________________________________
>Dev-cpp-users mailing list
>Dev...@li...
>TO UNSUBSCRIBE: http://www.noicys.cjb.net/devcpp/ub.htm
>https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
|
|
From: Ioannis V. <no...@ho...> - 2003-03-06 21:38:03
|
-------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
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
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'
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
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> 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
=0D
=0D
}=0D
=0D
The problem comes when I read the data from file. If I just reverse the
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
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
numbers (0 80 114).=0D
=0D
When looking at the filesize it shows that it is 85 bytes, but the data
written is only 82 bytes=0D
=0D
For debugging purposes, instead of writing directly to file, I first stor=
e
everything in a=0D
string s. That is, replacing foo << ... with s +=3D ... Finally I write i=
t to
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
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
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
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
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
its bit, marking its signess floats around. Also keep in mind that the
binary representation of negative values is radically different from the
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
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
|
|
From: Ioannis V. <no...@ho...> - 2003-03-06 21:43:18
|
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 |
|
From: <qa...@ho...> - 2003-03-06 23:00:10
|
See comments...
*********** REPLY SEPARATOR ***********
On 2003-03-06 at 23:42 Ioannis Vranos wrote:
Important correction:
-------Original Message-------
From: Ioannis Vranos
Date: =D0=DD=EC=F0=F4=E7, 6 =CC=DC=F1=F4=E9=EF=F2 2003 11:37:40 =EC=EC
To: Dev-C++ Mailing List
Subject: Re: [Dev-C++] Some extra bytes written to file?
-------Original Message-------
From: "J=F6rgen"
Date: =D0=DD=EC=F0=F4=E7, 6 =CC=DC=F1=F4=E9=EF=F2 2003 5:00:15 =EC=EC
To: dev...@li...
Subject: [Dev-C++] Some extra bytes written to file?
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=
data
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 'nbrOfValues'
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 the
following way
=3D=3D> Since it is C++, why don't you use bitset<> elegantly and=
efficiently?
[commment]
Where should I use it? I can't see the purpose for it.
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));
=3D=3D> CORRECTION: Since value2 is [0,65536] use unsigned long. E.g.
for(int i=3D0; i<numberOfValues; i++){
foo << static_cast<unsigned long> (value[i][0]) & 0x000000FF;
foo << static_cast<unsigned long>(value[i][1]) & 0x0000FF00 >> 8;
foo << static_cast<unsigned long> (value[i][1]) & 0x000000FF;
foo << static_cast<unsigned long> (value[i][2]) & 0x000000FF;
=3D=3D>CORRECTION: The casting should be applied "before" the bitwise=
operation.
[comment]
What I'm trying to do is to reduce the size of the written file. Casting to=
unsigned long gives me no reduction in size.
E.g.
4 * char =3D 4 * 8 =3D 32 bits =3D 4 bytes.
4 * unsigned long =3D 4 * 32 =3D 128 bits =3D 32 bytes
}
The problem comes when I read the data from file. If I just reverse the
procedure 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 80 114
It looks just the same as the original data except for the last three
numbers (0 80 114).
When looking at the filesize it shows that it is 85 bytes, but the data
written is only 82 bytes
For debugging purposes, instead of writing directly to file, I first store
everything in a
string s. That is, replacing foo << ... with s +=3D ... Finally 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' bytes
(d a 0 1b 2 , d a 0 24 1 , d a 0 36 1).
Where did these 'd' bytes come from?
=3D=3D> Truncation. You "bitwise" a signed value (casted to unsigned type)=
and
its bit, marking its signess floats around. Also keep in mind that the
binary representation of negative values is radically different from the
positive ones.
[comment]
First. There are no negative integers (int) in the data so the problem=
shouldn't be happening.
Second. Lets say that the value of the int to be casted is 130. In bits it=
is written
00000000 00000000 00000000 10000010
Then it is masket with
00000000 00000000 00000000 11111111
and the result is
00000000 00000000 00000000 10000010
Now it is casted to unsigned char and we got the following bits
10000010
The value is still 130. If it were a signed char the bitrepresentation=
would still be
10000010
but the value would be -126
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=
values
but instead
appends (0 80 114) at the end?
=3D=3D> Hmmm.
[comment]
Couldn't agree more
Ioannis Vranos
* Programming pages: http://www.noicys.freeurl.com
* Alternative URL: http://run.to/noicys
|
|
From: Per W. <pw...@ia...> - 2003-03-06 23:20:23
|
No problem about the extra 0x0d before a 0x0a.
Every heard about CR+LF, i.e. carriage return + line feed.
Whenever you open the file in text mode on a MSDos or Windows machine, you
will get the automatic addition, i.e. printf("hello\n"); will actually
emit "hello\r\n", and when you load the file in text mode, the extra CR
will be removed.
People normally only programming on Unix machines tries to forget this
little Microsoft extra, resulting in big problems reading and or writing
binary files.
/Per W
On Thu, 6 Mar 2003, "J=F6rgen" wrote:
> See comments...
>
> *********** REPLY SEPARATOR ***********
>
> On 2003-03-06 at 23:42 Ioannis Vranos wrote:
> Important correction:
>
>
> -------Original Message-------
>
> From: Ioannis Vranos
> Date: =D0=DD=EC=F0=F4=E7, 6 =CC=DC=F1=F4=E9=EF=F2 2003 11:37:40 =EC=EC
> To: Dev-C++ Mailing List
> Subject: Re: [Dev-C++] Some extra bytes written to file?
>
> -------Original Message-------
>
> From: "J=F6rgen"
> Date: =D0=DD=EC=F0=F4=E7, 6 =CC=DC=F1=F4=E9=EF=F2 2003 5:00:15 =EC=EC
> To: dev...@li...
> Subject: [Dev-C++] Some extra bytes written to file?
>
> 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
>
>
> =3D=3D> Since it is C++, why don't you use bitset<> elegantly and efficie=
ntly?
> [commment]
> Where should I use it? I can't see the purpose for it.
>
>
> 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));
>
>
> =3D=3D> CORRECTION: Since value2 is [0,65536] use unsigned long. E.g.
>
> for(int i=3D0; i<numberOfValues; i++){
> foo << static_cast<unsigned long> (value[i][0]) & 0x000000FF;
> foo << static_cast<unsigned long>(value[i][1]) & 0x0000FF00 >> 8;
> foo << static_cast<unsigned long> (value[i][1]) & 0x000000FF;
> foo << static_cast<unsigned long> (value[i][2]) & 0x000000FF;
>
>
> =3D=3D>CORRECTION: The casting should be applied "before" the bitwise ope=
ration.
> [comment]
> What I'm trying to do is to reduce the size of the written file. Casting =
to unsigned long gives me no reduction in size.
> E.g.
> 4 * char =3D 4 * 8 =3D 32 bits =3D 4 bytes.
> 4 * unsigned long =3D 4 * 32 =3D 128 bits =3D 32 bytes
>
>
>
>
> }
>
> The problem comes when I read the data from file. If I just reverse the
> procedure 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 80 114
>
> It looks just the same as the original data except for the last three
> numbers (0 80 114).
>
> When looking at the filesize it shows that it is 85 bytes, but the data
> written 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 ... Finally I write i=
t 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?
>
>
> =3D=3D> Truncation. You "bitwise" a signed value (casted to unsigned type=
) and
> its bit, marking its signess floats around. Also keep in mind that the
> binary representation of negative values is radically different from the
> positive ones.
>
> [comment]
> First. There are no negative integers (int) in the data so the problem sh=
ouldn't be happening.
> Second. Lets say that the value of the int to be casted is 130. In bits i=
t is written
> 00000000 00000000 00000000 10000010
> Then it is masket with
> 00000000 00000000 00000000 11111111
> and the result is
> 00000000 00000000 00000000 10000010
> Now it is casted to unsigned char and we got the following bits
> 10000010
> The value is still 130. If it were a signed char the bitrepresentation wo=
uld still be
> 10000010
> but the value would be -126
>
>
>
> 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?
>
>
> =3D=3D> Hmmm.
> [comment]
> Couldn't agree more
>
>
>
> Ioannis Vranos
>
> * Programming pages: http://www.noicys.freeurl.com
> * Alternative URL: http://run.to/noicys
>
>
|
|
From: <qa...@ho...> - 2003-03-06 23:41:55
|
Ahhh, I see. Thought there was a simple explanation to the problem.
/J=F6rgen
*********** REPLY SEPARATOR ***********
On 2003-03-07 at 00:18 Per Westermark wrote:
>No problem about the extra 0x0d before a 0x0a.
>
>Every heard about CR+LF, i.e. carriage return + line feed.
>
>Whenever you open the file in text mode on a MSDos or Windows machine, you
>will get the automatic addition, i.e. printf("hello\n"); will actually
>emit "hello\r\n", and when you load the file in text mode, the extra CR
>will be removed.
>
>People normally only programming on Unix machines tries to forget this
>little Microsoft extra, resulting in big problems reading and or writing
>binary files.
>
>/Per W
>
>On Thu, 6 Mar 2003, "J=F6rgen" wrote:
>
>> See comments...
>>
>> *********** REPLY SEPARATOR ***********
>>
>> On 2003-03-06 at 23:42 Ioannis Vranos wrote:
>> Important correction:
>>
>>
>> -------Original Message-------
>>
>> From: Ioannis Vranos
>> Date: =D0=DD=EC=F0=F4=E7, 6 =CC=DC=F1=F4=E9=EF=F2 2003 11:37:40 =EC=EC
>> To: Dev-C++ Mailing List
>> Subject: Re: [Dev-C++] Some extra bytes written to file?
>>
>> -------Original Message-------
>>
>> From: "J=F6rgen"
>> Date: =D0=DD=EC=F0=F4=E7, 6 =CC=DC=F1=F4=E9=EF=F2 2003 5:00:15 =EC=EC
>> To: dev...@li...
>> Subject: [Dev-C++] Some extra bytes written to file?
>>
>> 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
>data
>> 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
>'nbrOfValues'
>> 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
>the
>> following way
>>
>>
>> =3D=3D> Since it is C++, why don't you use bitset<> elegantly and
>efficiently?
>> [commment]
>> Where should I use it? I can't see the purpose for it.
>>
>>
>> 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));
>>
>>
>> =3D=3D> CORRECTION: Since value2 is [0,65536] use unsigned long. E.g.
>>
>> for(int i=3D0; i<numberOfValues; i++){
>> foo << static_cast<unsigned long> (value[i][0]) & 0x000000FF;
>> foo << static_cast<unsigned long>(value[i][1]) & 0x0000FF00 >> 8;
>> foo << static_cast<unsigned long> (value[i][1]) & 0x000000FF;
>> foo << static_cast<unsigned long> (value[i][2]) & 0x000000FF;
>>
>>
>> =3D=3D>CORRECTION: The casting should be applied "before" the bitwise
>operation.
>> [comment]
>> What I'm trying to do is to reduce the size of the written file. Casting
>to unsigned long gives me no reduction in size.
>> E.g.
>> 4 * char =3D 4 * 8 =3D 32 bits =3D 4 bytes.
>> 4 * unsigned long =3D 4 * 32 =3D 128 bits =3D 32 bytes
>>
>>
>>
>>
>> }
>>
>> The problem comes when I read the data from file. If I just reverse the
>> procedure 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 80 114
>>
>> It looks just the same as the original data except for the last three
>> numbers (0 80 114).
>>
>> When looking at the filesize it shows that it is 85 bytes, but the data
>> written is only 82 bytes
>>
>> For debugging purposes, instead of writing directly to file, I first
>store
>> everything in a
>> string s. That is, replacing foo << ... with s +=3D ... Finally 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'
>bytes
>> (d a 0 1b 2 , d a 0 24 1 , d a 0 36 1).
>>
>> Where did these 'd' bytes come from?
>>
>>
>> =3D=3D> Truncation. You "bitwise" a signed value (casted to unsigned=
type)
>and
>> its bit, marking its signess floats around. Also keep in mind that the
>> binary representation of negative values is radically different from the
>> positive ones.
>>
>> [comment]
>> First. There are no negative integers (int) in the data so the problem
>shouldn't be happening.
>> Second. Lets say that the value of the int to be casted is 130. In bits
>it is written
>> 00000000 00000000 00000000 10000010
>> Then it is masket with
>> 00000000 00000000 00000000 11111111
>> and the result is
>> 00000000 00000000 00000000 10000010
>> Now it is casted to unsigned char and we got the following bits
>> 10000010
>> The value is still 130. If it were a signed char the bitrepresentation
>would still be
>> 10000010
>> but the value would be -126
>>
>>
>>
>> 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
>values
>> but instead
>> appends (0 80 114) at the end?
>>
>>
>> =3D=3D> Hmmm.
>> [comment]
>> Couldn't agree more
>>
>>
>>
>> Ioannis Vranos
>>
>> * Programming pages: http://www.noicys.freeurl.com
>> * Alternative URL: http://run.to/noicys
>>
>>
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: Etnus, makers of TotalView, The
>debugger
>for complex code. Debugging C/C++ programs can leave you feeling lost and
>disoriented. TotalView can help you find your way. Available on major UNIX=
>and Linux platforms. Try it free. www.etnus.com
>_______________________________________________
>Dev-cpp-users mailing list
>Dev...@li...
>TO UNSUBSCRIBE: http://www.noicys.cjb.net/devcpp/ub.htm
>https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
|
|
From: Ioannis V. <no...@ho...> - 2003-03-07 02:34:17
|
-------Original Message-------=0D
=0D
From: Per Westermark=0D
Date: =D0=E1=F1=E1=F3=EA=E5=F5=DE, 7 =CC=DC=F1=F4=E9=EF=F2 2003 1:18:58 =F0=
=EC=0D
To: "J=F6rgen"=0D
Cc: Ioannis Vranos; dev...@li...=0D
Subject: Re: [Dev-C++] Some extra bytes written to file?=0D
=0D
No problem about the extra 0x0d before a 0x0a.=0D
=0D
Every heard about CR+LF, i.e. carriage return + line feed.=0D
=0D
Whenever you open the file in text mode on a MSDos or Windows machine, yo=
u=0D
will get the automatic addition, i.e. printf("hello\n"); will actually=0D
emit "hello\r\n", and when you load the file in text mode, the extra CR=0D
will be removed.=0D
=0D
People normally only programming on Unix machines tries to forget this=0D
little Microsoft extra, resulting in big problems reading and or writing=0D
binary files.=0D
=0D
=0D
=3D=3D> Yes, this is also the case to change line in .NET multiline Text =
boxes.
I can't understand why...=0D
=0D
=0D
=0D
Ioannis Vranos=0D
=0D
* Programming pages: http://www.noicys.freeurl.com=0D
* Alternative URL: http://run.to/noicys=20 |
|
From: Ioannis V. <no...@ho...> - 2003-03-07 02:30:54
|
-------Original Message-------=0D =0D From: "J=F6rgen"=0D Date: =D0=E1=F1=E1=F3=EA=E5=F5=DE, 7 =CC=DC=F1=F4=E9=EF=F2 2003 12:59:43 = =F0=EC=0D To: Ioannis Vranos; dev...@li...=0D Subject: Re: [Dev-C++] Some extra bytes written to file?=0D =0D See comments...=0D =0D =0D [comment] =0D What I'm trying to do is to reduce the size of the written file. Casting = to unsigned long gives=0D me no reduction in size.=0D E.g. =0D 4 * char =3D 4 * 8 =3D 32 bits =3D 4 bytes. =0D 4 * unsigned long =3D 4 * 32 =3D 128 bits =3D 32 bytes=0D =0D =0D =0D =3D=3D> At first as i said you apply casting wrong. =0D =0D =3D=3D> For example you wrote:=0D =0D foo << ((unsigned char) (value[i][0] & 0x000000FF)); =0D =0D =0D =3D=3D> But it should be:=0D =0D foo << (unsigned char) (value[i][0]) & 0x000000FF; =0D =0D or better:=0D =0D foo << static_cast<unsigned char> (value[i][0]) & 0x000000FF; =0D =0D =0D =3D=3D> or better you should have used bitset<unsigned whatever> from the beginning.=0D =0D =0D =3D=3D> After that, you are do these bitwise things to reduce the size? =0D =0D =3D=3D> Keep in mind that for size reduction, binary file mode is better = (but with the cost of non=0D file portability).=0D =0D =0D [comment]=0D =0D First. There are no negative integers (int) in the data so the problem shouldn't be happening.=0D Second. Lets say that the value of the int to be casted is 130. In bits i= t is written=0D 00000000 00000000 00000000 10000010=0D Then it is masket with =0D 00000000 00000000 00000000 11111111=0D and the result is=0D 00000000 00000000 00000000 10000010=0D Now it is casted to unsigned char and we got the following bits=0D 10000010=0D The value is still 130. If it were a signed char the bitrepresentation wo= uld still be=0D 10000010=0D but the value would be -126=0D =0D =0D =3D=3D> You can assume nothing about the implementation. You can assume a= fter the casting=0D which you did wrong. Also for values larger than numeric_limits<unsigned char>::max() you=0D get data truncation.=0D =0D =0D =0D =0D =0D Ioannis Vranos=0D =0D * Programming pages: http://www.noicys.freeurl.com=0D * Alternative URL: http://run.to/noicys=20 |
