Data alignment in structure in x86-64 [closed]
up vote
0
down vote
favorite
struct P1 short i; int c; int *j; short *d; ;
struct P4 char w[16]; char *c[2]; ;
struct P5 struct P4 a[2]; struct P1 t; ;
I have a couple of question about padding. I have learned that padding is applied by default.
So I think offset of struct P1 should be
i c j d total alignment
---------------------------------------
0 2 8 16 24 8
and for struct P5
a t total alignment
----------------------------
0 64 96 8
since total size of P4 is 32byte.
But the textbook solution is different. I think I am correct.
Solution suggests
i c j d total alignment
---------------------------------------
0 2 6 14 16 8
a t total alignment
----------------------------
0 24 40 8
c struct alignment
closed as too broad by Lundin, greg-449, TDG, Nicolas Filotto, Matthieu Brucher Nov 9 at 22:23
Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
add a comment |
up vote
0
down vote
favorite
struct P1 short i; int c; int *j; short *d; ;
struct P4 char w[16]; char *c[2]; ;
struct P5 struct P4 a[2]; struct P1 t; ;
I have a couple of question about padding. I have learned that padding is applied by default.
So I think offset of struct P1 should be
i c j d total alignment
---------------------------------------
0 2 8 16 24 8
and for struct P5
a t total alignment
----------------------------
0 64 96 8
since total size of P4 is 32byte.
But the textbook solution is different. I think I am correct.
Solution suggests
i c j d total alignment
---------------------------------------
0 2 6 14 16 8
a t total alignment
----------------------------
0 24 40 8
c struct alignment
closed as too broad by Lundin, greg-449, TDG, Nicolas Filotto, Matthieu Brucher Nov 9 at 22:23
Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
Don't think, find out for sure what happens with your particular compiler and os and CPU combination usingoffsetof()
. And realize it might be different with a different environment or different compiler flags.
– Shawn
Nov 9 at 3:03
1
The answer is implementation defined. Since you've not identified the implementation you are using, nor the implementation that the authors are using, no-one can help. You've not identified explicitly whether you're working with 32-bit or 64-bit pointers; that definitely factors into the answer. It is unlikely thatc
in thestruct P1
is 2; it is probably 4.
– Jonathan Leffler
Nov 9 at 4:05
It looks like the book is assuming 32-bit pointers whereas you're assuming 64-bit pointers. Yes, the answers will be different, therefore. Both correct, but both dependent on the specific implementation. (I still thinkc
won't be at offset 2 — it certainly isn't on a Mac running macOS 10.14.1 Mojave with GCC 8.2.0 or with Apple's Clang (Apple LLVM version 10.0.0 (clang-1000.11.45.5)).
– Jonathan Leffler
Nov 9 at 4:25
Unless you can edit the question and specify which system and compiler you have in mind, it isn't possible to answer - the question is too broad.
– Lundin
Nov 9 at 14:43
add a comment |
up vote
0
down vote
favorite
up vote
0
down vote
favorite
struct P1 short i; int c; int *j; short *d; ;
struct P4 char w[16]; char *c[2]; ;
struct P5 struct P4 a[2]; struct P1 t; ;
I have a couple of question about padding. I have learned that padding is applied by default.
So I think offset of struct P1 should be
i c j d total alignment
---------------------------------------
0 2 8 16 24 8
and for struct P5
a t total alignment
----------------------------
0 64 96 8
since total size of P4 is 32byte.
But the textbook solution is different. I think I am correct.
Solution suggests
i c j d total alignment
---------------------------------------
0 2 6 14 16 8
a t total alignment
----------------------------
0 24 40 8
c struct alignment
struct P1 short i; int c; int *j; short *d; ;
struct P4 char w[16]; char *c[2]; ;
struct P5 struct P4 a[2]; struct P1 t; ;
I have a couple of question about padding. I have learned that padding is applied by default.
So I think offset of struct P1 should be
i c j d total alignment
---------------------------------------
0 2 8 16 24 8
and for struct P5
a t total alignment
----------------------------
0 64 96 8
since total size of P4 is 32byte.
But the textbook solution is different. I think I am correct.
Solution suggests
i c j d total alignment
---------------------------------------
0 2 6 14 16 8
a t total alignment
----------------------------
0 24 40 8
c struct alignment
c struct alignment
edited Nov 9 at 4:00
Jonathan Leffler
556k886631016
556k886631016
asked Nov 9 at 2:19
cp3
14
14
closed as too broad by Lundin, greg-449, TDG, Nicolas Filotto, Matthieu Brucher Nov 9 at 22:23
Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
closed as too broad by Lundin, greg-449, TDG, Nicolas Filotto, Matthieu Brucher Nov 9 at 22:23
Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
Don't think, find out for sure what happens with your particular compiler and os and CPU combination usingoffsetof()
. And realize it might be different with a different environment or different compiler flags.
– Shawn
Nov 9 at 3:03
1
The answer is implementation defined. Since you've not identified the implementation you are using, nor the implementation that the authors are using, no-one can help. You've not identified explicitly whether you're working with 32-bit or 64-bit pointers; that definitely factors into the answer. It is unlikely thatc
in thestruct P1
is 2; it is probably 4.
– Jonathan Leffler
Nov 9 at 4:05
It looks like the book is assuming 32-bit pointers whereas you're assuming 64-bit pointers. Yes, the answers will be different, therefore. Both correct, but both dependent on the specific implementation. (I still thinkc
won't be at offset 2 — it certainly isn't on a Mac running macOS 10.14.1 Mojave with GCC 8.2.0 or with Apple's Clang (Apple LLVM version 10.0.0 (clang-1000.11.45.5)).
– Jonathan Leffler
Nov 9 at 4:25
Unless you can edit the question and specify which system and compiler you have in mind, it isn't possible to answer - the question is too broad.
– Lundin
Nov 9 at 14:43
add a comment |
Don't think, find out for sure what happens with your particular compiler and os and CPU combination usingoffsetof()
. And realize it might be different with a different environment or different compiler flags.
– Shawn
Nov 9 at 3:03
1
The answer is implementation defined. Since you've not identified the implementation you are using, nor the implementation that the authors are using, no-one can help. You've not identified explicitly whether you're working with 32-bit or 64-bit pointers; that definitely factors into the answer. It is unlikely thatc
in thestruct P1
is 2; it is probably 4.
– Jonathan Leffler
Nov 9 at 4:05
It looks like the book is assuming 32-bit pointers whereas you're assuming 64-bit pointers. Yes, the answers will be different, therefore. Both correct, but both dependent on the specific implementation. (I still thinkc
won't be at offset 2 — it certainly isn't on a Mac running macOS 10.14.1 Mojave with GCC 8.2.0 or with Apple's Clang (Apple LLVM version 10.0.0 (clang-1000.11.45.5)).
– Jonathan Leffler
Nov 9 at 4:25
Unless you can edit the question and specify which system and compiler you have in mind, it isn't possible to answer - the question is too broad.
– Lundin
Nov 9 at 14:43
Don't think, find out for sure what happens with your particular compiler and os and CPU combination using
offsetof()
. And realize it might be different with a different environment or different compiler flags.– Shawn
Nov 9 at 3:03
Don't think, find out for sure what happens with your particular compiler and os and CPU combination using
offsetof()
. And realize it might be different with a different environment or different compiler flags.– Shawn
Nov 9 at 3:03
1
1
The answer is implementation defined. Since you've not identified the implementation you are using, nor the implementation that the authors are using, no-one can help. You've not identified explicitly whether you're working with 32-bit or 64-bit pointers; that definitely factors into the answer. It is unlikely that
c
in the struct P1
is 2; it is probably 4.– Jonathan Leffler
Nov 9 at 4:05
The answer is implementation defined. Since you've not identified the implementation you are using, nor the implementation that the authors are using, no-one can help. You've not identified explicitly whether you're working with 32-bit or 64-bit pointers; that definitely factors into the answer. It is unlikely that
c
in the struct P1
is 2; it is probably 4.– Jonathan Leffler
Nov 9 at 4:05
It looks like the book is assuming 32-bit pointers whereas you're assuming 64-bit pointers. Yes, the answers will be different, therefore. Both correct, but both dependent on the specific implementation. (I still think
c
won't be at offset 2 — it certainly isn't on a Mac running macOS 10.14.1 Mojave with GCC 8.2.0 or with Apple's Clang (Apple LLVM version 10.0.0 (clang-1000.11.45.5)).– Jonathan Leffler
Nov 9 at 4:25
It looks like the book is assuming 32-bit pointers whereas you're assuming 64-bit pointers. Yes, the answers will be different, therefore. Both correct, but both dependent on the specific implementation. (I still think
c
won't be at offset 2 — it certainly isn't on a Mac running macOS 10.14.1 Mojave with GCC 8.2.0 or with Apple's Clang (Apple LLVM version 10.0.0 (clang-1000.11.45.5)).– Jonathan Leffler
Nov 9 at 4:25
Unless you can edit the question and specify which system and compiler you have in mind, it isn't possible to answer - the question is too broad.
– Lundin
Nov 9 at 14:43
Unless you can edit the question and specify which system and compiler you have in mind, it isn't possible to answer - the question is too broad.
– Lundin
Nov 9 at 14:43
add a comment |
1 Answer
1
active
oldest
votes
up vote
1
down vote
The exact details of structure padding are implementation defined. However, compilers do tend to place fields at an alignment suitable for their type.
Assuming 8 byte pointers (given that you're on an x86-64 machine) 4 byte int
and 2 byte short
, you're mostly correct. The c
field in P1
, being an int
, will probably start at a 4 byte offset, but the rest of the fields should be at the same offsets. The size of P5
will also only need to be 88 (64 for 2 P4's and 24 for 1 P1) since only 8 byte alignment would be required as opposed to 16 byte alignment.
Given this code:
printf("sizeof p1 = %zun", sizeof(struct P1));
printf("sizeof p4 = %zun", sizeof(struct P4));
printf("sizeof p5 = %zun", sizeof(struct P5));
printf("P1 offset: %zu, %zu, %zu, %zun",
offsetof(struct P1, i), offsetof(struct P1, c),
offsetof(struct P1, j), offsetof(struct P1, d));
printf("P4 offset: %zu, %zun",
offsetof(struct P4, w), offsetof(struct P4, c));
printf("P5 offset: %zu, %zun",
offsetof(struct P5, a), offsetof(struct P5, t));
My x86-64 CentOS 7 machine with gcc 4.8.5 outputs:
sizeof p1 = 24
sizeof p4 = 32
sizeof p5 = 88
P1 offset: 0, 4, 8, 16
P4 offset: 0, 16
P5 offset: 0, 64
The book you're using seems to be using 4 byte pointers and assumes either no alignment or packed structures.
For more details, take a look at The Lost Art of Structure Padding.
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
The exact details of structure padding are implementation defined. However, compilers do tend to place fields at an alignment suitable for their type.
Assuming 8 byte pointers (given that you're on an x86-64 machine) 4 byte int
and 2 byte short
, you're mostly correct. The c
field in P1
, being an int
, will probably start at a 4 byte offset, but the rest of the fields should be at the same offsets. The size of P5
will also only need to be 88 (64 for 2 P4's and 24 for 1 P1) since only 8 byte alignment would be required as opposed to 16 byte alignment.
Given this code:
printf("sizeof p1 = %zun", sizeof(struct P1));
printf("sizeof p4 = %zun", sizeof(struct P4));
printf("sizeof p5 = %zun", sizeof(struct P5));
printf("P1 offset: %zu, %zu, %zu, %zun",
offsetof(struct P1, i), offsetof(struct P1, c),
offsetof(struct P1, j), offsetof(struct P1, d));
printf("P4 offset: %zu, %zun",
offsetof(struct P4, w), offsetof(struct P4, c));
printf("P5 offset: %zu, %zun",
offsetof(struct P5, a), offsetof(struct P5, t));
My x86-64 CentOS 7 machine with gcc 4.8.5 outputs:
sizeof p1 = 24
sizeof p4 = 32
sizeof p5 = 88
P1 offset: 0, 4, 8, 16
P4 offset: 0, 16
P5 offset: 0, 64
The book you're using seems to be using 4 byte pointers and assumes either no alignment or packed structures.
For more details, take a look at The Lost Art of Structure Padding.
add a comment |
up vote
1
down vote
The exact details of structure padding are implementation defined. However, compilers do tend to place fields at an alignment suitable for their type.
Assuming 8 byte pointers (given that you're on an x86-64 machine) 4 byte int
and 2 byte short
, you're mostly correct. The c
field in P1
, being an int
, will probably start at a 4 byte offset, but the rest of the fields should be at the same offsets. The size of P5
will also only need to be 88 (64 for 2 P4's and 24 for 1 P1) since only 8 byte alignment would be required as opposed to 16 byte alignment.
Given this code:
printf("sizeof p1 = %zun", sizeof(struct P1));
printf("sizeof p4 = %zun", sizeof(struct P4));
printf("sizeof p5 = %zun", sizeof(struct P5));
printf("P1 offset: %zu, %zu, %zu, %zun",
offsetof(struct P1, i), offsetof(struct P1, c),
offsetof(struct P1, j), offsetof(struct P1, d));
printf("P4 offset: %zu, %zun",
offsetof(struct P4, w), offsetof(struct P4, c));
printf("P5 offset: %zu, %zun",
offsetof(struct P5, a), offsetof(struct P5, t));
My x86-64 CentOS 7 machine with gcc 4.8.5 outputs:
sizeof p1 = 24
sizeof p4 = 32
sizeof p5 = 88
P1 offset: 0, 4, 8, 16
P4 offset: 0, 16
P5 offset: 0, 64
The book you're using seems to be using 4 byte pointers and assumes either no alignment or packed structures.
For more details, take a look at The Lost Art of Structure Padding.
add a comment |
up vote
1
down vote
up vote
1
down vote
The exact details of structure padding are implementation defined. However, compilers do tend to place fields at an alignment suitable for their type.
Assuming 8 byte pointers (given that you're on an x86-64 machine) 4 byte int
and 2 byte short
, you're mostly correct. The c
field in P1
, being an int
, will probably start at a 4 byte offset, but the rest of the fields should be at the same offsets. The size of P5
will also only need to be 88 (64 for 2 P4's and 24 for 1 P1) since only 8 byte alignment would be required as opposed to 16 byte alignment.
Given this code:
printf("sizeof p1 = %zun", sizeof(struct P1));
printf("sizeof p4 = %zun", sizeof(struct P4));
printf("sizeof p5 = %zun", sizeof(struct P5));
printf("P1 offset: %zu, %zu, %zu, %zun",
offsetof(struct P1, i), offsetof(struct P1, c),
offsetof(struct P1, j), offsetof(struct P1, d));
printf("P4 offset: %zu, %zun",
offsetof(struct P4, w), offsetof(struct P4, c));
printf("P5 offset: %zu, %zun",
offsetof(struct P5, a), offsetof(struct P5, t));
My x86-64 CentOS 7 machine with gcc 4.8.5 outputs:
sizeof p1 = 24
sizeof p4 = 32
sizeof p5 = 88
P1 offset: 0, 4, 8, 16
P4 offset: 0, 16
P5 offset: 0, 64
The book you're using seems to be using 4 byte pointers and assumes either no alignment or packed structures.
For more details, take a look at The Lost Art of Structure Padding.
The exact details of structure padding are implementation defined. However, compilers do tend to place fields at an alignment suitable for their type.
Assuming 8 byte pointers (given that you're on an x86-64 machine) 4 byte int
and 2 byte short
, you're mostly correct. The c
field in P1
, being an int
, will probably start at a 4 byte offset, but the rest of the fields should be at the same offsets. The size of P5
will also only need to be 88 (64 for 2 P4's and 24 for 1 P1) since only 8 byte alignment would be required as opposed to 16 byte alignment.
Given this code:
printf("sizeof p1 = %zun", sizeof(struct P1));
printf("sizeof p4 = %zun", sizeof(struct P4));
printf("sizeof p5 = %zun", sizeof(struct P5));
printf("P1 offset: %zu, %zu, %zu, %zun",
offsetof(struct P1, i), offsetof(struct P1, c),
offsetof(struct P1, j), offsetof(struct P1, d));
printf("P4 offset: %zu, %zun",
offsetof(struct P4, w), offsetof(struct P4, c));
printf("P5 offset: %zu, %zun",
offsetof(struct P5, a), offsetof(struct P5, t));
My x86-64 CentOS 7 machine with gcc 4.8.5 outputs:
sizeof p1 = 24
sizeof p4 = 32
sizeof p5 = 88
P1 offset: 0, 4, 8, 16
P4 offset: 0, 16
P5 offset: 0, 64
The book you're using seems to be using 4 byte pointers and assumes either no alignment or packed structures.
For more details, take a look at The Lost Art of Structure Padding.
answered Nov 9 at 4:30
dbush
90.8k12100131
90.8k12100131
add a comment |
add a comment |
Don't think, find out for sure what happens with your particular compiler and os and CPU combination using
offsetof()
. And realize it might be different with a different environment or different compiler flags.– Shawn
Nov 9 at 3:03
1
The answer is implementation defined. Since you've not identified the implementation you are using, nor the implementation that the authors are using, no-one can help. You've not identified explicitly whether you're working with 32-bit or 64-bit pointers; that definitely factors into the answer. It is unlikely that
c
in thestruct P1
is 2; it is probably 4.– Jonathan Leffler
Nov 9 at 4:05
It looks like the book is assuming 32-bit pointers whereas you're assuming 64-bit pointers. Yes, the answers will be different, therefore. Both correct, but both dependent on the specific implementation. (I still think
c
won't be at offset 2 — it certainly isn't on a Mac running macOS 10.14.1 Mojave with GCC 8.2.0 or with Apple's Clang (Apple LLVM version 10.0.0 (clang-1000.11.45.5)).– Jonathan Leffler
Nov 9 at 4:25
Unless you can edit the question and specify which system and compiler you have in mind, it isn't possible to answer - the question is too broad.
– Lundin
Nov 9 at 14:43