Internal mechanism of sizeof in C?

问题

I use sizeof to get size of a struct in C, but the result I got is unexpected.

struct sdshdr {
    int len;
    int free;
    char buf[];
};


int main(){
    printf("struct len:%d\n",(sizeof(struct sdshdr)));
    return 0;
} //struct len:8, with or without buf

my question is why does buf not occupy any space and why is the size of the int type still 4 on a 64-bit CPU?

here is the output from gcc -v:

Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn)
Target: x86_64-apple-darwin14.4.0
Thread model: posix

回答1:

The [] is a flexible array member. They do not count towards the total size of the struct, because the C standard explicitly says so:

6.7.2.1/18

As a special case, the last element of a structure with more than one named member may have an incomplete array type; this is called a flexible array member. In most situations, the flexible array member is ignored. In particular, the size of the structure is as if the flexible array member were omitted except that it may have more trailing padding than the omission would imply.

This is intentional by design, because the purpose of a flexible array member is to allow you to allocate trailing data dynamically after the struct. (When the struct is a file header, protocol header etc.)

Example including discussion about non-standard gcc extensions and the old pre-C99 "struct hack".

回答2:

From C99 onwards the size of an array at the end of a struct may be omitted. For purposes of sizeof(struct) this array will appear to have zero size (although its presence may add some padding to the struct), but the intent is for its length to be flexible, i.e., when allocating space for the struct one must allocate the desired amount of extra space for the array at the end. (To avoid going out of bounds, the actual allocated length of the array should be stored somewhere.)

Before C99 it was a fairly common hack to have an array of size 1 (or 0 where allowed by the compiler) at the end of a struct and then allocate more space for it, so C99 made this practice explicitly allowed by introducing the flexible array member with no size given.

回答3:

As a GNU c extension, you have zero-length arrays:

As a GNU extension, the number of elements can be as small as zero. Zero-length arrays are useful as the last element of a structure which is really a header for a variable-length object:

for example, consider this code from The gnu c manual

 struct line
 {
   int length;
   char contents[0];
 };

 {
   struct line *this_line = (struct line *)
     malloc (sizeof (struct line) + this_length);
   this_line -> length = this_length;
 }

In ISO C99, you would use a flexible array member, which is slightly different in syntax and semantics:

Flexible array members are written as contents[] without the 0.

Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero.

Flexible array members may only appear as the last member of a struct that is otherwise non-empty.

A structure containing a flexible array member, or a union containing such a structure (possibly recursively), may not be a member of a structure or an element of an array. (However, these uses are permitted by GCC as extensions.)

回答4:

buf here is a flexible array member Flexible array members have incomplete type, and so the sizeof operator may not be applied whereas original implementation of zero-length arrays, sizeof evaluates to zero.

来源：https://stackoverflow.com/questions/31318740/internal-mechanism-of-sizeof-in-c

标签

gcc

sizeof

flexible-array-member