Strange sizeof() behaviour

This is a discussion on Strange sizeof() behaviour within the C++ Programming forums, part of the General Programming Boards category; While debugging with gdb is found out that Code: sizeof(ChunkHeader) returns 8(!) messing up my program. Code: struct ChunkHeader { ...

  1. #1
    Registered User
    Join Date
    Jul 2010
    Posts
    27

    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
    [...]

  2. #2
    The larch
    Join Date
    May 2006
    Posts
    3,573
    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).
    I might be wrong.

    Thank you, anon. You sure know how to recognize different types of trees from quite a long way away.
    Quoted more than 1000 times (I hope).

  3. #3
    Registered User
    Join Date
    Jul 2010
    Posts
    27
    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.

  4. #4
    Registered User
    Join Date
    Oct 2008
    Posts
    1,262
    Quote Originally Posted by Phenom View Post
    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).

  5. #5
    Registered User hk_mp5kpdw's Avatar
    Join Date
    Jan 2002
    Location
    Northern Virginia/Washington DC Metropolitan Area
    Posts
    3,799
    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).
    "Owners of dogs will have noticed that, if you provide them with food and water and shelter and affection, they will think you are god. Whereas owners of cats are compelled to realize that, if you provide them with food and water and shelter and affection, they draw the conclusion that they are gods."
    -Christopher Hitchens

  6. #6
    The larch
    Join Date
    May 2006
    Posts
    3,573
    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.
    I might be wrong.

    Thank you, anon. You sure know how to recognize different types of trees from quite a long way away.
    Quoted more than 1000 times (I hope).

  7. #7
    Registered User
    Join Date
    Jun 2005
    Posts
    6,245
    Quote Originally Posted by anon View Post
    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.
    Right 98% of the time, and don't care about the other 3%.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. strange scanf behaviour
    By cavva in forum C Programming
    Replies: 3
    Last Post: 08-10-2009, 12:44 PM
  2. Strange behaviour of GCC
    By BlackOps in forum C Programming
    Replies: 14
    Last Post: 07-29-2009, 06:44 PM
  3. Replies: 14
    Last Post: 06-28-2006, 01:58 AM
  4. Strange problem with bmp
    By Victor in forum Linux Programming
    Replies: 2
    Last Post: 04-04-2005, 02:48 PM
  5. GetClientRect strange behaviour
    By btq in forum Windows Programming
    Replies: 2
    Last Post: 10-02-2002, 02:13 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21