how are ints chars and longs etc represented?

[peterworth]

is it 2's compliment when signed and plain binary when unsigned?

the problem is that i am reading the first 4 bytes from a buffer like this:

DWORD ret = *lpBufComp;

and this comes out as 4294967168 which i believe is 0x7FFFFFFF. however, i'm sure it should be (in binary) 100000000..... sure enough, if i replace this line with:

UCHAR ret = *lpBufComp;

the ret comes out as 128 = 10000000 in base 2. why would the DWORD be the exact inversion of the actual bit values in the buffer?

 

[Salem]

> and this comes out as 4294967168 which i believe is 0x7FFFFFFF
Mmm, it seems to be 0xFFFFFF80 here.

Which is far more consistent with the 0x80 you get when you read the first byte.


--

 

[peterworth]

ah.. interesting, how did you calculate that?

if that is the case, why is it not 80FFFFFF? is that something to do with it being little endian?

 

[peterworth]

my problem has now come down to this now:

(unsigned long)838868 >> 23;

as far as i can see should be 256, but it comes out as 1 or 0.

838868 base 10
= 1000 0000 0000 0000 0000 0000 0000 0000 base 2

and if the 1 is shifted 23 bits to the right we have

1 0000 0000
= 256 base 10

why is this not the case?

 

[cpjust]

838,868 decimal = 1100 1100 1100 1101 0100 binary

2,147,483,648 decimal = 1000 0000 0000 0000 0000 0000 0000 0000 binary

 

[Salem]

> ah.. interesting, how did you calculate that?
Copied it into calculator, then clicked 'hex'


--

 

[peterworth]

hmm.. not sure whats wrong with my calculator (it can't be my fault my sums are wrong).

 

[EarlAllen]

Easy to make mistakes when converting from one number base to another. Instead, if you have VS, DEBUG the program and set breakpoints where the value is calculated. In the watch window, you can right mouse click the field and select hex or non-hex formatting.

 

[mingis]

> why is it not 80FFFFFF? is that something to do with it being little endian?

sure