sizeof unsigned int is 8

Question

I am confused why clientIf even though declared as uint32(unsigned int - size 4 bytes), is taking up 8 bytes. I have explicitly printed sizeof(uint32) and that shows 4 bytes.

Can someone throw some insight.

I am running this code on a little endian machine x86.

#include <stdio.h>
#include <string.h>

/* network defines */
typedef char uint8;
typedef short uint16;
typedef unsigned int uint32;
typedef uint32 ipv4Addr;

/***********************    V6 IP ADDRESS   **********************************/
typedef struct _v6IpAddr
{
    union _Bytes
    {
        uint8       rbyte[16];
        uint16      doublebyte[8];
        uint32      wordbyte[4];
        long long   dwordbyte[2];
    }unionv6;
#define dbyte   unionv6.doublebyte
#define wbyte   unionv6.wordbyte
#define dwbyte  unionv6.dwordbyte
#define xbyte   unionv6.rbyte
}v6IpAddr;

typedef struct _v6IpAddr uint128;

typedef union _comIpAddr
{
    ipv4Addr v4Ip;
    v6IpAddr v6Ip;
}comIpAddr;

typedef struct abc
{
    /*|*/uint32         clientIf;          /*|*/
    /*|*/comIpAddr      clientIp;          /*|*/
    /*|*/uint8          mac[6];            /*|*/
    /*|*/uint16         zero;              /*|*/
}ABC;

void print_bytes(const void *object, size_t size)
{
  // This is for C++; in C just drop the static_cast<>() and assign.
  const unsigned char * const bytes = object;
  size_t i;

  printf("[ ");
  for(i = 0; i < size; i++)
  {
    printf("%02x ", bytes[i]);
  }
  printf("]\n");
}

int main()
{
    ABC test;
    memset(&test,0,sizeof test);
    printf("sizeof test = %u\n", sizeof test);
    printf("%d-%d-%d\n", sizeof(uint8), sizeof(uint16), sizeof(uint32));

    print_bytes(&test, sizeof test);
    test.clientIf = 10;
    test.clientIp.v4Ip = 0xAABBCCDD;
    print_bytes(&test, sizeof test);
    printf("%p-%p-%p\n", &(test.clientIf), &(test.clientIp), &(test.clientIp.v4Ip));
    return 0;
}

$ ./a.out

sizeof test = 32

1-2-4

[ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ]

[ 0a 00 00 00 00 00 00 00 dd cc bb aa 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ]

0x7fff113b0780-0x7fff113b0788-0x7fff113b0788 $

Edit:

Why will compiler add padding after clientIf since it is already a multiple of 4 bytes?

The location of *where* a variable is allocated is not an indication of it's *size*. Variables are often padded for various reasons such as alignment and access optimization. — Eugene Sh., May 23 '18 at 17:23
Aside: you should not use `%d` for `sizeof` but `%zu`. The `sizeof` gives a value of type `size_t` which *might* be the same size as `int`, or maybe not. — Weather Vane, May 23 '18 at 17:24
Even though it can be of same size, it **must not be** `int` since `size_t` must be unsigned, therefore `%d` is still not compliant even on those platforms — Antti Haapala -- Слава Україні, May 23 '18 at 17:37
@AnttiHaapala I only meant that OP could have "got away with it" in this case, which was apparently so. — Weather Vane, May 23 '18 at 17:38
if you want to understand why this is happening look here https://en.wikipedia.org/wiki/Data_structure_alignment — pm100, May 23 '18 at 18:00
Why does the tile of the question talk about "sizeof unsigned int" when in reality it is about "sizeof ABC"??? — AnT stands with Russia, May 23 '18 at 18:11

j123b567 · Answer 1 · 2018-05-23T17:51:02.010

It is up to the compiler how it aligns memory. You can try to use __attribute__ ((__packed__)) if using GCC or similar compiler or #pragma pack(push,1) and #pragma pack(pop) if using Visual C.

It is not portable way to do things and it can break on some compilers/systems but it can work for you.

Packing can save the memory but accessing variables may be slower.

Edit:

What can break if using packed:

Some compilers can ignore packing at all in some cases (e.g. there was/is? a bug in mingw-gcc)

Some CPU architectures can't handle unaligned access to memory. They throw an exception/fault or they just use wrong values. (e.g. ARMv5 and older ARM cores). Compiler can overcome this issue in some cases but not in all cases.

"can break on some compilers" = can break on *any* compiler anywhere. Including those platforms that supposedly allow unaligned access. — Antti Haapala -- Слава Україні, May 23 '18 at 17:39

score 1 · Answer 2 · answered May 23 '18 at 17:35

As others pointed out in comments, offset of an element in a struct is not a reliable way to measure its as your compiler is free to insert padding to structs in order to enforce specific member alignment.

If you want your structs not to include padding for various reason, you have to use a compiler specific pragma to do it.

For GCC, Clang and MSVC, you have to add #pragma pack(push, 1) right before your struct definition and #pragma pack(pop) right after it.

score 0 · Answer 3 · answered May 23 '18 at 18:08

Structs will typically be padded for alignment purposes. An 8-byte type will want 8-byte alignment, so if it follows a 4-byte type, there may be 4 bytes of padding added so the 8-byte type can have its proper alignment. Some compilers have extensions that will allow you to throw alignment to the wind (as shown in some of the other answers), but that comes with the problem of relying on compiler-specific extensions and unaligned members which, depending on the underlying hardware, can result in speed penalties or even traps (SPARC, for example, cannot handle unaligned access).

Instead of relying on such behavior, if you order the struct by strictest alignment requirements first, it should naturally pack nicely without the alignment issues, though you might still wind up with some padding at the end so the struct itself can be aligned.

sizeof unsigned int is 8

3 Answers3