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

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

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
> >>
> >>
>
>
>
>