tags:

views:

104

answers:

4

Hey,

I have a a struct defined thusly:

typedef struct _CONFIGURATION_DATA {
    BYTE configurationIndicator;
    ULONG32 baudRate;
    BYTE stopBits;
    BYTE parity;
    BYTE wordLength;
    BYTE flowControl;
    BYTE padding;
} CONFIGURATION_DATA;

Now, by my reckoning, that struct is 10 bytes long. However, sizeof reports that it is 16 bytes long? Anyone know why?

I am compiling using the build tools in the Windows DDK.

+2  A: 

Change the order of the elements. Start with the ULONG, followed by the BYTEs. This will improve the struct's alignment in memory.

Rik
+6  A: 

Alignment.

use

#pragma pack(1)

...struct goes here...

#pragma pack()

I would also recommend reordering things, and if necessary padding then with RESERVED bytes, so that multi-byte integral types will be better aligned. This will make processing faster for tbe CPU, and your code smaller.

Pavel Radzivilovsky
That did the trick, cheers.
Kazar
Only do this if you've got a good reason to -- many architectures disallow misaligned accesses (so the compiler will have to use byte loads and saves for safety) and most introduce a performance penalty.
Andrew Aylett
True. But I'd expect the compiler to generate proper instructions to access misaligned integral types when architecture does not support it. This is a common pattern to access binary data in files, communications and other IO. On the contrary, i'd say avoid writing a structure if you do not specify the alignment explicitly, because it will change with compiler version/settings.
Pavel Radzivilovsky
Actually, the reason i need it packed like this is because it gets written to a socket, and the communications spec dicatates a 10-byte message.
Kazar
@Pavel -- you might 'expect' the compiler to do something but there is no guarantee that it will! For example the MS VC++ cross-compiler will not automatically generate instructions for misaligned types, you have to explicitly tell it to do so using pointers declared with __unaligned.
AAT
@Pavel: I certainly wouldn't "expect" that. You're just spoiled because you're used to x86 hardware. Writing programs that crash at the slightest provocation is a "common pattern" too.
jalf
@jalf, AAT: by "expect", I mean exactly this: "compiler is the proper abstraction layer where handing alignment misfortune belongs". For instance, tightly packed struct members should be treated by MSVC just as __unaligned. All other compilers should be inserting the bit magic, because in this particular case the compiler can know that pointer may be unaligned.
Pavel Radzivilovsky
BTW, `#pragma pack` is not part of the standard and not necessary supported by all compilers. A better method is to provide an interface for reading and writing fields to a packed buffer.
Thomas Matthews
+3  A: 

This is due to padding, because on your platform, an ULONG32 apparently must be aligned on 4-byte boundaries. Since the start and end of the struct apparently also must be aligned, the first and last BYTE will be padded with 3 bytes each.

Thomas
+2  A: 

The extra size you are measuring is the padding introduced by the compiler.

Presumably, you are working on a 32 bits system, so you will have 3 bytes of padding between configurationIndicator and baudRate, and 3 more bytes of padding at the end of the struct.

ddaa