There's actually no problem with the data.
The problem is you're using the wrong way to print them.
Try replacing your code:
printf("%d\n",source_info.DataOffSet);
printf("%d\n",source_info.Width*source_info.Height);
for(i=0;i<16;i++)
fprintf(Dfp,"%d\t",source_info.data[i]);
with this:
printf("%x\n",source_info.DataOffSet);
printf("%x\n",source_info.Width*source_info.Height);
for(i=0;i<16;i++)
fprintf(Dfp,"%x\t",source_info.data[i]);
As %d
is for signed decimals while %x
is for hexadecimals. See the section of The conversion specifier
in the manual page of printf
EDITED:
As you've posted your new questions in the comments:
output in hex is 0x00 0xffffff 0x3f 0x3f 0x3f 0x5f 0x5f 0x5f 0x1f 0x1f 0x1f 0x1f 0x1f 0x1f 0x1f 0x1f Can u explain how the output is getting stored? I'm unable to get the same output – user2967899 7 mins ago
here's my edited answer.
Assumptions: your working platform is just as normal, on which size of short
is 2 bytes and of long
it's 4.
From definition of struct BitMap
we know the field data
is at its offset of 0x36. Comparing of the image we know the data shall be (in hexadecimal):
data[0]: 0000 0000
data[1]: ffff ff00
......
Then the result you got seems strange since data[1]
is 0x00ffffffff
instead of 0xffffff00
. However that's correct. This is cause by endianess, for which please read this wiki page first: http://en.wikipedia.org/wiki/Endianness
As the hex-editor represents data in the real order of bytes, and I assume you're working with a little-endian machine (which most PC on this planet has), this order is just reversed of the real order of your data in long
:
/* data in C */
unsigned long x = 305419896; /* 305419896 == 0x12345678 */
/* arithmetically the four bytes in x: */
/* 0x12 0x34 0x56 0x78 */
/* the real order to be observed in a hex-editor due to endianess: */
/* 0x78 0x56 0x34 0x12 */
/* so this holds true in C: */
unsigned char *a = &x;
assert(a[0] == 0x78);
assert(a[1] == 0x56);
assert(a[2] == 0x34);
assert(a[3] == 0x12);