There's <stdint.h>, which should have defined types (int8_t/int16_t/int32_t, etc) with fixed sizes on all supported platforms.

See https://en.wikibooks.org/wiki/C_Programming/C_Reference/stdint.h#Exact-width_integer_types

How do I ensure, that WORD is always 2 Bytes and DWORD always 4 Bytes across diffrent hosts?

I've been taught that diffrent CPU-architectures define different sizes for the data types.

So, how can I ensure having the right size of the variable?

Just to be clear, they're not talking about different cpu architectures like going from a windows machine with an Intel processor to running the same program on an AMD processor. That is talking about going from an x86 family processor (like your PC) over to an ARM family processor like your cell phone. Or potentially they're talking about moving from a 32-bit compiler to a 64-bit compiler. You have to actually change architectures, which means a whole lot of things change.

If you are running the same executable on all the different machines the sizes will be the same.

The other thing to consider is padding inside the structure. Just because a field is 32 bits or 16 bits does not mean they are packed the same. Padding inside structures is an implementation detail in this language, but must be a specific spacing for file formats. They could all be aligned on byte boundaries, or 2-byte boundaries, or 4-byte boundaries, or 16-byte boundaries, or whatever else the compiler feels like doing. There are compiler-specific commands to adjust that.

Endian-ness will be another concern if you are going cross platform. While the values are the same as far as your code is concerned (the value is 12345678) the actual encoding of the byte pattern can be different. On one platform a 16 bit value may be encoded as AB, on another it is BA. For a 32 bit value it may be ABCD or DCBA or on some middle endian hardware potentially BADC.

These concerns don't really apply if you are talking about staying on a single architecture, such as building a program that only runs on 32-bit windows, or only runs on 64-bit windows.

Just to be clear, they're not talking about different cpu architectures like going from a windows machine with an Intel processor to running the same program on an AMD processor. That is talking about going from an x86 family processor (like your PC) over to an ARM family processor like your cell phone. Or potentially they're talking about moving from a 32-bit compiler to a 64-bit compiler. You have to actually change architectures, which means a whole lot of things change.

The size of these standard types also depend on the platform ABI. For example, the standard C type "long" is only 4 bytes on 64 bit Windows but 8 bytes on most other 64 bit platforms.

I didn't know that C++ compilers do use padding for their structs. My mind was already blown when I encountered this with HLSL.
How can I ensure that it is packed as one unit without padding? I am looking forward to support Linux and Windows.

There are compiler switches and pragmas you can use but then you suddenly have to code to support different compilers and make sure that the size of the struct is the same as the ZIP header if you ever plan on reading and writing the entire struct at once. Reading or writing one field at a time using the integer types from the stdint header is guaranteed to work on platforms where those integer types exist so that's the option I would go for (don't forget to account for the endianness though). If you want maximum portability then you're in for a real headache since some platforms might not even have integer types of the same length as those in the ZIP header. It can be solved by messing around with bit masks but it's not something I would bother with unless I knew I was targeting esoteric platforms.

@frob:
I didn't know that C++ compilers do use padding for their structs. My mind was already blown when I encountered this with HLSL.
How can I ensure that it is packed as one unit without padding? I am looking forward to support Linux and Windows.


The problem with "cstdint" is that it only offers datatypes with 8 bytes or more (correct me if this is wrong).

PKWare defined their ZIP-Headers using 4 and 2 Bytes.

I really don't want to use bitsets or "high/low orders".

The number at the end (uint8_t, int16_t, etc...) is the number of BITS not the number of bytes. So on a x86/x64 machine BYTE = uint8_t = 1 byte, WORD = uint16_t = 2 bytes, DWORD = uint32_t = 4 bytes, QWORD = uint64_t = 8 bytes.