Consider the following code:<\/p>\n\n\n\n
int main()\n{\n struct s {\n int m0;\n int m1;\n int m2;\n };\n\n struct s *p = NULL;\n int a = (int) &((struct s *)p)->m2; \/\/ crash ??\n int b = (int) &((struct s *)0)->m2; \/\/ crash ??\n int c = (int) p->m2; \/\/ definitely dead\n\n return 0;\n}<\/pre>\n\n\n\nSo, do you think the above two highlighted lines will crash the program? Well, at least to me, it will, since they’re dereferencing null pointers. Take, int b = (int) &((struct s *)0)->m2;<\/code>, for example, we first dereference the zero pointer to get the member m2<\/code>, and then obtain its address. Right? This is how we literally<\/em> read &p_struct->member<\/code>.<\/p>\n\n\n\nHowever, this is not how the compiler interprets it. The compiler is a very cool and knowledgeable guy who is assumed to know everything<\/em>. So the compiler knows the offset of each member in a structure<\/strong>, and he says, “Well, why do I even care for the values of those members (dereferencing)? To obtain the address of a member in a structure, I just need to add the offset of the member to the address of the structure: &p_struct->member := p_struct + offset(member)<\/code>.”<\/p>\n\n\n\nWith such ability, the compiler now can generate assembly code<\/p>\n\n\n\n
6 {\n 0x0000000000001129 <+0>: endbr64\n 0x000000000000112d <+4>: push %rbp\n 0x000000000000112e <+5>: mov %rsp,%rbp\n\n7 struct s {\n8 int m0;\n9 int m1;\n10 int m2;\n11 };\n12\n13 struct s *p = NULL;\n 0x0000000000001131 <+8>: movq $0x0,-0x8(%rbp)\n\n14 int a = (int) &((struct s *)p)->m2; \/\/ okay\n 0x0000000000001139 <+16>: mov -0x8(%rbp),%rax\n 0x000000000000113d <+20>: add $0x8,%rax\n 0x0000000000001141 <+24>: mov %eax,-0x14(%rbp)\n\n15 int b = (int) &((struct s *)0)->m2; \/\/ okay\n 0x0000000000001144 <+27>: movl $0x8,-0x10(%rbp)\n\n16 int c = (int) p->m2; \/\/ dead\n 0x000000000000114b <+34>: mov -0x8(%rbp),%rax\n 0x000000000000114f <+38>: mov 0x8(%rax),%eax # segfault, since it tries to access invalid memory address 0x8 (page 0)\n 0x0000000000001152 <+41>: mov %eax,-0xc(%rbp)\n\n17\n18 return 0;\n 0x0000000000001155 <+44>: mov $0x0,%eax\n\n19 }\n 0x000000000000115a <+49>: pop %rbp\n 0x000000000000115b <+50>: ret<\/pre>\n\n\n\nWe can see that there are no dereferences whatsoever when we try to get the address of a member in a structure, just the addition of the member offset to the address of the structure.<\/p>\n\n\n\n
Therefore, as a special case with the structure address being zero, &((TYPE *)0)->MEMBER<\/code> yields the exact offset of the member in a structure, which accounts for why the macro<\/p>\n\n\n\n#define offsetof(TYPE, MEMBER) ((size_t) &((TYPE *)0)->MEMBER)<\/pre>\n\n\n\nworks in the Linux kernel.<\/p>\n","protected":false},"excerpt":{"rendered":"
Consider the following code: So, do you think the above two highlighted lines will crash the program? Well, at least to me, it will, since they’re dereferencing null pointers. Take, int b = (int) &((struct s *)0)->m2;, for example, we first dereference the zero pointer to get the member m2, and then obtain its address. … <\/p>\n