Why if i check with the xxd an image eg. small.bmp the bfType is 0x424d and when you run copy in GDB the value of bf.bfType is 19778 and the program "copy" in line 55 check with 0x4d42. Is it reading it reverse order.
bfType is an unsigned 16 bit integer (ie, 2 bytes long, aka a WORD).
What you are seeing is the fact that
xxd displays byte by byte, but
gdb displays the word.
So why does it matter?
Intel processors use what is called "little endian" to store bytes in memory. That means that the least significant byte is stored in the first memory address in the word.
So gdb is showing you the decimal value 19778 (even though, in reality, bfType is 2 chars (B and M) and not an integer). If you convert to hex (which I think you've done) it is
0x4D42. That is the value that
copy.c is testing against.
0x4D42 in a little endian system will be stored in byte order as
xxd is showing you).
One way to think about little endian is to think of a decimal number.
If you write
123, the least significant number is
3 and it is at the end, so our number system of writing is "big endian", the opposite of what our computers use.
If our number system was "little endian", then we would write "one hundred twenty three" as 321.
The entry for Endianness on Wikipedia can explain it much more detail.
But let's look at an example from the class. If you take
small.bmp that is given and run
xxd to see the individual bytes, you'll get this. I've added spaces between some bytes to make it clearer:
424d 5a000000 00000000 36000000 28000000 03000000 fdffffff 0100 1800 00000000 24000000 120b0000 120b0000 00000000 00000000 00ff00 00ff00 00ff00 00 00 00 00ff00 ffffff 00ff00 00 00 00 00ff00 00ff00 00ff00 00 00 00
So you've got a printout of the bytes of the file. What do they mean? This is where you use the
bmp.h file to get the structure. Recall from the typedef's that a WORD is a unsigned 16 bit (ie, 2 byte) integer, a DWORD is an unsigned 32 bit (4 byte) integer and a LONG is a signed 32 bit (4 byte) integer. So we can then just count the bytes as we go along and assign them to their values.
Remember that the bytes are stored in little-endian fashion, with least significant byte stored first, so to calculate the decimal value, we need to think of them in the opposite order.
BITMAPFILEHEADER: Bytes: Hex = Decimal value: WORD bfType; 42 4d 0x4d42 = 19778 DWORD bfSize; 5a 00 00 00 0x0000005a = 90 WORD bfReserved1; 00 00 0x0000 = 0 WORD bfReserved2; 00 00 0x0000 = 0 DWORD bfOffBits; 36 00 00 00 0x00000036 = 54 BITMAPINFOHEADER: DWORD biSize; 28 00 00 00 0x00000028 = 40 LONG biWidth; 03 00 00 00 0x00000003 = 3 LONG biHeight; fd ff ff ff 0xfffffffd = -3 WORD biPlanes; 01 00 0x0001 = 1 WORD biBitCount; 18 00 0x0018 = 24 DWORD biCompression; 00 00 00 00 0x00000000 = 0 DWORD biSizeImage; 24 00 00 00 0x00000024 = 36 LONG biXPelsPerMeter; 12 0b 00 00 0x00000b12 = 2834 LONG biYPelsPerMeter; 12 0b 00 00 0x00000b12 = 2834 DWORD biClrUsed; 00 00 00 00 0x00000000 = 0 DWORD biClrImportant; 00 00 00 00 0x00000000 = 0 RGBTRIPLE: BYTE rgbtBlue; 00 0x00 = 0 BYTE rgbtGreen; ff 0xff = 255 BYTE rgbtRed; 00 etc... 0x00 = 0
Those values in the last column should match what you see if you use the
peek program to look at the headers of
Hope that helps, Brenda.