Thread: Loading a bitmap

I suspect this is actually the alignment inside the struct, which causes the size to be too large. You probably will find that some of the data is incorrect inside the struct.

--
Mats

Originally Posted by brewbuck

This is why you should not use sizeof() on a struct to load packed binary data from a file. It ignores alignment and endian issues.

You can't just imagine that the struct overlays perfectly on a section of file data. Things don't work that way.

And removing sizeof() will solve exactly which part of the problem? I'm sure you mean the right thing, but sizeof() itself is not a culprit in this case - the struct itself holds 16 bit and 32 bit data intermixed in ways that cause the compiler to add padding - in the middle of the struct. So alignment is very much the issue here.

--
Mats

Originally Posted by matsp

And removing sizeof() will solve exactly which part of the problem? I'm sure you mean the right thing, but sizeof() itself is not a culprit in this case - the struct itself holds 16 bit and 32 bit data intermixed in ways that cause the compiler to add padding - in the middle of the struct. So alignment is very much the issue here.

--
Mats

I didn't say that sizeof() was the problem. I (implicitly) was saying that the whole concept of taking a struct, laying it out like some portion of a file format, then using sizeof() to compute its size and read it as a single chunk, is wrong.

Further, if you follow the rule "never use sizeof() while reading a file format" then you eliminate a whole class of errors, like the aforementioned, as well as assuming a particular endianness and integer width. Without sizeof(), you are forced to read a single byte at a time, which forces you to deal with endianness and width from the very outset instead of ignoring them.

These are the structs provided by Microsoft.

Code:

typedef struct tagBITMAPFILEHEADER { 
  WORD    bfType; 
  DWORD   bfSize; 
  WORD    bfReserved1; 
  WORD    bfReserved2; 
  DWORD   bfOffBits; 
} BITMAPFILEHEADER, *PBITMAPFILEHEADER;

typedef struct tagBITMAPINFOHEADER{
  DWORD  biSize; 
  LONG   biWidth; 
  LONG   biHeight; 
  WORD   biPlanes; 
  WORD   biBitCount; 
  DWORD  biCompression; 
  DWORD  biSizeImage; 
  LONG   biXPelsPerMeter; 
  LONG   biYPelsPerMeter; 
  DWORD  biClrUsed; 
  DWORD  biClrImportant; 
} BITMAPINFOHEADER, *PBITMAPINFOHEADER;

Which equal:

Code:

typedef struct tagBITMAPFILEHEADER { 
  unsigned short bfType; 
  unsigned long  bfSize; 
  unsigned short bfReserved1; 
  unsigned short bfReserved2; 
  unsigned long  bfOffBits; 
} BITMAPFILEHEADER, *PBITMAPFILEHEADER;

typedef struct tagBITMAPINFOHEADER{
  unsigned long  biSize; 
  long           biWidth; 
  long           biHeight; 
  unsigned short biPlanes; 
  unsigned short biBitCount; 
  unsigned long  biCompression; 
  unsigned long  biSizeImage; 
  long           biXPelsPerMeter; 
  long           biYPelsPerMeter; 
  unsigned long  biClrUsed; 
  unsigned long  biClrImportant; 
} BITMAPINFOHEADER, *PBITMAPINFOHEADER;

I remember I have used these once to read bitmap files. Microsoft itself uses this way too...

And GameDev has this as a tutorial too: http://www.gamedev.net/reference/art...rticle1966.asp

Maybe add this line in front of the structure (not sure if it's standard):

Code:

#pragma pack(2)

It is not very important, but MSDN says that biWidth, biHeight, biXPelsPerMeter and biYPelsPerMeter are signed integers...

I'm not sure if it is true but in case if the program is compiled under x64 environment then int would be 8 bytes... maybe it would be better to use long as it is always 4 bytes.

Originally Posted by maxorator

I'm not sure if it is true but in case if the program is compiled under x64 environment then int would be 8 bytes... maybe it would be better to use long as it is always 4 bytes.

Ehm, it's the other way around. An int is 4 bytes in both 32 and 64 bit, but a long is 64-bit in a 64-bit architecture [although that is not guaranteed either].

--
Mats

> maybe it would be better to use long as it is always 4 bytes.
No, the guaranteed minimum is 4 bytes (assuming CHAR_BIT is 8). The standard specifies minimum data ranges for each type, but an implementation is free to choose larger ranges if it wants to.

> I thought the size of int is defined as the width of the data bus, is that really wrong info?
A couple of counter examples.
- Your PC is still capable of running DOS compilers with their 16 bit ints, despite your processor having a 32 (or even 64) bit data bus. But back then when it was still an 8086, it would have been a 16 bit bus and a 16 bit processor.
- The ill-fated Sinclair QL used a processor with an 8-bit bus but a 16/32-bit internal architecture.

A slightly better heuristic is int is the same size as the processor arithmetic registers.

Originally Posted by Salem

A slightly better heuristic is int is the same size as the processor arithmetic registers.

But that doesn't work for 64-bit machines - many 64-bit systems have a int that is 32-bit, and a long that is 64-bit. Or both being 32-bit.

But the language makes no guarantees about the size of a pointer.

Note also that LONG and long aren't the same thing - the former is a "local symbol", e.g. something that Microsoft have designed, whilst long is part of the C language.

--
Mats

Then I wonder why MS uses LONG in their structures. :O