Read width and height of bmp file in C++ - c++

Question

I'm trying read width and height of bmp file in C++. width and height is 512 of my bmp file. 18. byte is width value of bmp files.
My code show below:
int main() {
char header[54];
ifstream bmp;
bmp.open("image.bmp", ios::in | ios::binary);
if (!bmp) {
cout << "Error" << endl;
system("PAUSE");
exit(1);
}
bmp.read(header, 54);
char a = header[18];
int b = *(int *)&header[18];
system("PAUSE");
}
How does b become 512 when a is '\0' ? Sorry my bad English.

Answer 1

Because char is one byte and int is (probably) 4 bytes. 512 as a four-byte int would look something like 0x00 0x00 0x02 0x00. Notice that only one of those four bytes is non-zero.
char a = header[18]; just reads the single byte at position 18, while int b = *(int *)&header[18]; interprets positions 18 through 21 as a single int value.

Answer 2

According to the BMP file format, the width is a signed integer comprising 4 bytes, not one byte.
So if the width is 512, then - when represented as a 4 byte integer, the bytes are 0x00 - 0x00 - 0x02 - 0x00 and stored from position 18 to 21, respectively. So position 18 is 0x00 (your value of a), whereas the width when interpreted as a 4 byte signed integer from position 18 to 21 is 512.

Answer 3

Important note that I'm not certain can be expanded upon in a comment.
int b = *(int *)&header[18];
treats header[18] as though it was an int. It's not an int. Welcome to Strict Aliasing. You have converted types which are not the same What you do here is walk into undefined behaviour. It's one of the sort of Undefined behaviour that USUALLY "works", but consider this:
header[18] is not 32 or 64 bit byte aligned. Reading a 32 or 64 bit integer the program will suffer a performance hit as the processor plays games to read the unaligned data or die a painful death as the processor raises its digital middle finger and outright crashes.
The almost correct way to do this is
int width;
memcpy(&width, &header[18], sizeof(width));
But this ignores the fact that the header and the program may disagree on the size and byte order of an int.
Looking at the BMP spec, the image width is a little endian unsigned 16 bit integer. Reading that into the typical 32 bit int is going to result in utter garbage. At the very least use a uint16_t instead and pray for a little endian processor (a reasonable assumption on PC hardware).
uint16_t width;
memcpy(&width, &header[18], sizeof(width));
Better
uint16_t width = (uint8_t)header[19];
width <<= 8;
width += (uint8_t)header[18];
or similar to make sure the bytes go in the right order regardless of the native endian.