use on "unusual" CPU's about pixmap565

[plerros]

The BMP format is defined using bytes.
It has words and dwords that are 2 and 4 bytes respectively.

Unsigned short is bigger or equal to 2 bytes.
I am not using uint16_t for words, because it may be smaller than 2 bytes.

Unsigned long is bigger or equal to 4 bytes.
I am not using uint32_t for dwords, because it may be smaller than 4 bytes.

The code will probably work on almost all 32-bit and 64-bit systems. (I don't have 8 or 16 bit CPUs to test it on.)

[plerros]

On the "unusual" CPUs matter.
I am not referring to how many bits the cpu is.
I am referring to the size of the byte, the smallest addressable memory.

From wikipedia:
The pixel array is a block of 32-bit DWORDs.

This statement is problematic, because you could have 36-bit bytes.
In such a case, a DWORD would be 144-bits (36 * 4).

A non 8-bit byte causes many issues, like:

1. What happens to a file, if you copy it from an 8-bit byte computer to a 36-bit byte computer?

• If the number of bytes stay the same:
  byte pixel_array_offset + 0:
  [XXXX XXXXXXXX XXXXXXXX XXXXXXXX GGGBBBBB]
  byte pixel_array_offset + 1:
  [XXXX XXXXXXXX XXXXXXXX XXXXXXXX RRRRRGGG]

  But the code would write out:
  byte pixel_array_offset + 0:
  [XXXX XXXXXXXX XXXXXXXX RRRRRGGG GGGBBBBB]

  So, no buneno.

• If the number of bytes change:
  The whole file would be broken.
  The fields filesize, DIB_size and pixel_array_offset rely on bytes.

2. How would you write 16 bits (a pixel), if the smallest addressable memory is 36 bits?

• You could pack multiple pixels in a byte and then write it out, but 36 isn't divisible by 16, and you'd have to carry over the remaining bits