2

The following code:

#include <stdint.h>

uint8_t  byte = 0x12;
uint16_t word = 0x1234;

int main(int argc, char *argv[])
{

        return 0;
}

Inspecting the .data section, it shows that byte variable 2 bytes, not 1 as uint8_t promises:

Hex dump of section '.data':
  0x00601020 00000000 00000000 00000000 00000000 ................
  0x00601030 12003412                            ..4.

How can we ensure that byte is 1 byte, even it makes the memory misaligned? I tried adding #pragam pack(1) but it's still the same.

Tu Do
  • 339
  • 2
  • 11
  • Is there a specific reason you want that? – Sami Kuhmonen Dec 06 '16 at 09:30
  • Why would you ever want to disable [stack alignment and padding](http://stackoverflow.com/questions/1061818/stack-allocation-padding-and-alignment)? – Zach P Dec 06 '16 at 09:35
  • Because I wonder if the `byte` variable is used as 2 bytes, not 1 byte. But it seems, when I tried setting `byte = -1`, only a single byte changed to `ff`. It seems `gcc` ensures that the padding bytes won't be used through all the generated code.. – Tu Do Dec 06 '16 at 09:41
  • Of course a byte variable will not use two bytes. The whole purpose of the zero byte in between is to align the variable correctly and gcc must make sure it isn't used erroneously. – cadaniluk Dec 06 '16 at 09:44
  • move `uint16_t word = 0x1234;` to before `uint8_t byte = 0x12;` – phuclv Dec 06 '16 at 09:45

1 Answers1

1

byte variable 2 bytes, not 1 as uint8_t promises

Variable is 1 but compiler pads it to 2 bytes. Note that this does not affect total section size (it'll still be aligned to 2 bytes).

How can we ensure that byte is 1 byte, even it makes the memory misaligned?

Why would you want to do that? On many platforms this will cause compiler to generate inefficient code for memory accesses so you'll loose anything you squeeze from variable alignments due to code size increase. If you absolutely must use unaligned globals, mark them with __attribute__((aligned(1))).

yugr
  • 19,769
  • 3
  • 51
  • 96