Strange sizeof() behaviour

While debugging with gdb is found out that

Code:

sizeof(ChunkHeader)

returns 8(!) messing up my program.

Code:

struct ChunkHeader
{
    unsigned short id;
    unsigned int   lenght;
};

I use gcc 4.5.1

Code:

C:\>g++ --version
g++ <tdm-1> 4.5.1
[...]

The struct is padded with unused bytes so that fields are aligned to suitable boundaries (length member to a 4-byte boundary here).

This is normal for all structs, so you should never assume that sizeof(struct) equals the sum of sizeof(member).

Thanks for advice.

What do I have to do if I want sizeof(ChunkHeader) to return 6? I think I've seen a pragma directive that can do this.

Originally Posted by Phenom

Thanks for advice.

What do I have to do if I want sizeof(ChunkHeader) to return 6? I think I've seen a pragma directive that can do this.

Google it. "Structure packing gcc". I don't know because I've never used it and I post this because I can tell you it's better not to.
See, even if your structure is packed you can't simply convert a character array to this string: there's still issues such as endianness. So it would decrease the portability of your program.

Okay, if you don't care the slightest about portability, continue with packing the structure. But it's best if you simply read it member-after-member from the character array (or file or whatever).

You might get different results (6 vs 8) if you switch around the order of your struct's members:

Code:

struct ChunkHeader
{
    unsigned int   lenght;
    unsigned short id;
};

And that might help in this instance (struct with only two members).

You might get different results (6 vs 8) if you switch around the order of your struct's members

Most likely not, because if you were to make an array of those, the first member would still be better aligned to a 4-byte boundary.

Putting largest members first helps to reduce the size, because it reduces need for potential padding between members but doesn't do away with padding at the end of the structure.

Besides, most likely OP is trying to reinterpret_cast a char buffer into a header.

Originally Posted by anon

Most likely not, because if you were to make an array of those, the first member would still be better aligned to a 4-byte boundary.

That's not strictly true: there are quite a few systems that do not require alignment on 4-byte boundaries.

Anything related to padding for alignment of struct members is in the realm of implementation-defined behaviour - it is specifically allowed to vary between compilers and, in practice, does.

hk_mp5kpdw's advice is correct, in the sense that "members in order of decreasing size" allows the compiler greatest freedom to minimise the number of packing bytes that it must introduce into a struct. However, minimise is not the same as eliminate - that is why they are distinct words.