Storing an unsigned integer into a struct

Question

I've written this piece of code where I've assigned an unsigned integer to two different structs. In fact they're the same but one of them has the __attribute__((packed)).

  #include 
  #include 

  struct st1{
    unsigned char opcode[3];
    unsigned int target;
  }__attribute__((packed));

  struct st2{
    unsigned char opcode[3];
    unsigned int target;
  };


  void proc(void* addr) {
    struct st1* varst1 = (struct st1*)addr;
    struct st2* varst2 = (struct st2*)addr;
    printf("opcode in varst1: %c,%c, %c\n",varst1->opcode[0],varst1->opcode[1],varst1->opcode[2]);
    printf("opcode in varst2: %c,%c,%c\n",varst2->opcode[0],varst2->opcode[1],varst2->opcode[2]);
    printf("target in varst1: %d\n",varst1->target);
    printf("target in varst2: %d\n",varst2->target);

  };

  int main(int argc,char* argv[]) {
    unsigned int* var;
    var =(unsigned int*) malloc(sizeof(unsigned int));
    *var = 0x11334433;

    proc((void*)var);

    return 0;
  }

The output is:

opcode in varst1: 3,D,3 opcode in varst2: 3,D,3 target in varst1: 17 target in varst2: 0

Given that I'm storing this number 0x11334433 == 00010001001100110100010000110011

I'd like to know why is that the output I get.

Answer 1

• %c interprets the argument as the ascii code of a character and prints the character
• 3's ascii code is 0x33
• D's ascii code is 0x44
• 17 is 0x11

an int is stored little endian or big endian depending on the processor architecture -- you can't depend on it going into your struct's fields in order.

The int target in the unpacked version is past the position of the int, so it stays 0.

Answer 2

Your bytes look like this:

00010001 00110011 01000100 00110011

Though obviously your endianness is wrong and in fact they're like this:

00110011 01000100 00110011 00010001

If your struct is packed then the first three bytes are associated with opcode, and the 4th is target - thats why the packed array has atarget of 17 - 0001001 in binary.

The unpacked array is padded with zeros, which is why target in varst2 is zero.

Answer 3

This is to do with data alignment. Most compilers will align data on address boundaries that help with general performance. So, in the first case, the struct with the packed attribute, there is an extra byte between the char [3] and the int to align the int on a four byte boundary. In the packed version that padding byte is missing.

byte  :      0       1         2         3      4   5   6   7
st1   : opcode[0] opcode[1] opcode[2] padding |----int------|
st2   : opcode[0] opcode[1] opcode[2] |-------int--------|

You allocate an unsigned int and pass that to the function:

byte  :      0       1         2         3      4   5   6   7
alloc :   |-----------int------------------| |---unallocated---|
st1   : opcode[0] opcode[1] opcode[2] padding |----int------|
st2   : opcode[0] opcode[1] opcode[2] |-------int--------|

If you're using a little endian system then the lowest eight bits (right most) are stored at byte 0 (0x33), byte 1 has 0x44, byte 2 has 0x33 and byte 4 has 0x11. In the st1 structure the int value is mapped to memory beyond the end of the allocated amount and the st2 version the lowest byte of the int is mapped to the byte 4, 0x11. So st1 produces 0 and st2 produces 0x11.

You are lucky that the unallocated memory is zero and that you have no memory range checking going on. Writing to the ints in st1 and st2 in this case could corrupt memory at worst, generate memory guard errors or do nothing. It is undefined and dependant on the runtime implementation of the memory manager.

In general, avoid "void *".

Skizz