C Structure Padding

Anyone know where is the reference of C Structure Padding?

I mean, how do they pad data inside a structure?

Thanks in advance :D

Look in the documentation for your compiler.
It's nothing to do with the standard.

The standard basically says two things
- the first element is aligned with the beginning of the structure
- the struct members are in the order written in the source code

Quote:

---

Look in the documentation for your compiler.
It's nothing to do with the standard.

---

Does GCC/MSVC have it? I don't think so :D

Quote:

---

Originally Posted by audinue

Does GCC/MSVC have it? I don't think so :D

---

What do you mean, "do they have it?" If you mean do they pad structures, then the answer is assuredly "yes". If you mean do they pad structures the same way, then maybe maybe not.

Quote:

---

What do you mean, "do they have it?"

---

he probably meant, do they have some doc. For intel-like cpu, gcc generally tries to align fields on 32 bits (there is an option to align on 64 bits, this is probably the default for 64 bits arch). But see by yourself: create a structure with differents types and output the offsets. Anyway, the idea is that you should not have to care about that, except out of curiosity, otherwise, work with [byte] arrays if you have to control padding or include appropriate (non portable) directives or options to compact a structure ('info gcc' for details, if you do use gcc).

By "pad" I presume you mean you want (for example) to make a 16 byte struct out of a 14 byte one. It would seem the best way to do this is with an extra char array, as it may be the only way to insure the exact number of bytes. I noticed with my compiler that if you use a short as a two byte pad, it may get further padded up to a full word. int unused:16 gives two bytes, but in this example (if you swapped char unused[2] for int unused), int unused:8 will also add 2 bytes and a just plain int unused actually adds 6 bytes (all the way to 20, according to sizeof(struct example)). I guess this is because the int is starting in the middle of a word and not on a word boundary.

Code:

---

struct example {
          char one[7];
          char two[7];
          char unused[2];
}

---

Quote:

---

Originally Posted by MK27

By "pad" I presume you mean you want (for example) to make a 16 byte struct out of a 14 byte one. It would seem the best way to do this is with an extra char array, as it may be the only way to insure the exact number of bytes. I noticed with my compiler that if you use a short as a two byte pad, it may get further padded up to a full word. int unused:16 gives two bytes, but in this example (if you swapped char unused[2] for int unused), int unused:8 will also add 2 bytes and a just plain int unused actually adds 6 bytes (all the way to 20, according to sizeof(struct example)). I guess this is because the int is starting in the middle of a word and not on a word boundary.

Code:

---

struct example {
          char one[7];
          char two[7];
          char unused[2];
}

---

---

Your belief that there's not a padding byte between one and two, and between two and unused, is probably incorrect.

Edit: Actually, looking with offsetof, using int there's no padding between one and two, but there is between two and unused. (And there's only two bytes of padding, as 7+7+4=18.)

The only way to ensure the struct has the right size is to disable padding and that is a compiler-specific option that differs between compilers.

Quote:

---

Originally Posted by tabstop

Your belief that there's not a padding byte between one and two, and between two and unused, is probably incorrect.

Edit: Actually, looking with offsetof, using int there's no padding between one and two, but there is between two and unused. (And there's only two bytes of padding, as 7+7+4=18.)

---

Hmm. But sizeof(struct example) will always return the correct value, correct?

(I assume these are compiler differences because this one is 16 bytes for me, which means the compiler didn't add anything. But as mentioned, if I use int unused, I get 20 bytes which I guess is 7+7+2+4).

Yes, it will return the actual size.

Quote:

---

7+7+2+4

---

There must be a formula to count that :D Anyone know?

Quote:

---

Originally Posted by MK27

Hmm. But sizeof(struct example) will always return the correct value, correct?

(I assume these are compiler differences because this one is 16 bytes for me, which means the compiler didn't add anything. But as mentioned, if I use int unused, I get 20 bytes which I guess is 7+7+2+4).

---

Right. Reading it again, I think I misinterpreted what you said -- I thought you meant six bytes of padding, where you meant "adds six bytes" in that the int was four and there were two bytes of padding.

Quote:

---

Originally Posted by audinue

There must be a formula to count that :D Anyone know?

---

It's called offsetof in stddef.h.

Quote:

---

Originally Posted by MK27

(I assume these are compiler differences because this one is 16 bytes for me, which means the compiler didn't add anything. But as mentioned, if I use int unused, I get 20 bytes which I guess is 7+7+2+4).

---

Perhaps it is 8 + 8 + 4?
However, we can say that most compilers will strive to align variables to boundaries, typically 4 or 8 bytes.

Quote:

---

Originally Posted by Elysia

Perhaps it is 8 + 8 + 4?
However, we can say that most compilers will strive to align variables to boundaries, typically 4 or 8 bytes.

---

Nope, it's definitely (at least on this machine) 7+7+2+4. I haven't tried it in VS.

It would make more sense that it aligned the odd chars on a DWORD boundary, though. At least to me.

Quote:

---

Originally Posted by Elysia

It would make more sense that it aligned the odd chars on a DWORD boundary, though. At least to me.

---

Wild guessing: Presumably this is so, if someone like cus comes along who wants to copy one struct into another struct, and the struct that person is copying has just the two char arrays in it (and not everything else), then the alignments still match. After all, chars don't align on a DWORD.

Quote:

---

Nope, it's definitely (at least on this machine) 7+7+2+4.

---

Yes this is possible, bytes and byte arrays are aligned by definition, so no padding is required here, only objects greater than 1 byte (and accessed as such) have to be aligned.

Structure Padding is done to do memory alignment. As size of pointer is 4 bytes, if everything is organized by multiple of 4, that it will be easier and faster to calculate the address and processing them. Structure padding in C

Ok, we get it. Welcome to the forum. Now please stop bumping old threads with what you just learned today. (Based on ALL the other threads bumped).

I have deleted the other zombie posts.

*thread closed*