GNU C的定义长度为0的数组

最新推荐文章于 2022-07-20 13:56:50 发布

weixin_30518397

最新推荐文章于 2022-07-20 13:56:50 发布

阅读量85

点赞数

文章标签：操作系统 c/c++

原文链接：http://www.cnblogs.com/Spider-spiders/p/8807760.html

版权

在标准C和C++中，长度为0的数组是被禁止使用的。不过在GNU C中，存在一个非常奇怪的用法，那就是长度为0的数组，比如Array[0];很多人可能觉得不可思议，长度为0的数组是没有什么意义的，不过在这儿，它表示的完全是另外的一层意思，这个特性是不可移植的，所以，如果你致力于编写可移植，或者是稍稍需要跨平台的代码，这些Trick最好还是收起来的好。

在GNU的指南中，它是如此写道：

struct line

{

int length;

char contents[0];

};

//...ommit code here

{

struct line *thisline = (struct line *) malloc (sizeof (struct line) + this_length);

thisline->length = this_length;

}

这个用法主要用于变长Buffer，struct line的大小为4，结构体中的contents[0]不占用任何空间，甚至是一个指针的空间都不占，contents在这儿只是表示一个常量指针，这个特性是用编译器来实现的，即在使用thisline->contents的时候，这个指针就是表示分配内存地址中的某块buffer，比如 malloc (sizeof (struct line) + this_length)返回的是0x8f00a40,thisline->contents指向的位置就是(0x8f00a40 + sizeof(struct line)),而这儿sizeof(struct line)仅仅是一个int的四字节。

对于这个用法，我们定义的结构体指针可以指向任意长度的内存buffer，这个技巧在变长buffer中使用起来相当方便。

可能有朋友说，为什么不把最后的contents直接定义为一个指针呢？这儿的差别是这样的，如果定义为一个指针，它需要占用4Bytes，并且在申请好内存后必须人为赋地址才可以。如果使用这个用法，这个常量指针不占用空间，并且无需赋值。

但是，方便并不是绝对的，在释放分配的内存的时候，由于函数free会认为*thisline 只是指向一个4字节的指针，即只会释放length的空间，而对于后面占据大头的buffer却视而不见，这个就需要人为干预；而对于后面的声明指针的方式，则可以直接用Free(thisline->contents)的方式释放掉分配的内存。 ASSERT:除非必要，不要轻易使用这个功能，GNU C下可以编译通过，所以你在使用vc++，那就不用尝试了，编译都无法通过。

总结：

用途：长度为0的数组的主要用途是为了满足需要变长度的结构体。

用法：在一个结构体的最后，申明一个长度为0的数组，就可以使得这个结构体是可变长的。对于编译器来说，此时长度为0的数组并不占用空间，因为数组名本身不占空间，它只是一个偏移量，数组名这个符号本身代表了一个不可修改的地址常量（注意：数组名永远都不会是指针！），但对于这个数组的大小，我们可以进行动态分配。例如：

typedef struct{ int len; char data[0]; }test_t;

int my_length = 10;

test_t *p_test = (test_t *)malloc(sizeof(test_t) + my_length); p_test->len = my_length;

......

free(p_test);

之后对于结构体中的数组可以像一般的数组一样进行访问。

注意：如果结构体是通过calloc、malloc或者new等动态分配方式生成，在不需要时要释放相应的空间。

优点：比起在结构体中声明一个指针变量、再进行动态分配的办法，这种方法效率要高。因为在访问数组内容时，不需要间接访问，避免了两次访存。

缺点：在结构体中，数组为0的数组必须在最后声明，使用上有一定限制。

另一篇解释：

在Linux系统里，/usr/include/linux/if_pppox.h里面有这样一个结构： struct pppoe_tag { __u16 tag_type; __u16 tag_len; char tag_data[0]; } __attribute ((packed)); 最后一个成员为可变长的数组，对于TLV（Type-Length-Value）形式的结构，或者其他需要变长度的结构体，用这种方式定义最好。使用起来非常方便，创建时，malloc一段结构体大小加上可变长数据长度的空间给它，可变长部分可按数组的方式访问，释放时，直接把整个结构体free掉就可以了。例子如下： struct pppoe_tag *sample_tag; __u16 sample_tag_len = 10; sample_tag = (struct pppoe_tag *)malloc(sizeof(struct pppoe_tag)+sizeof(char)*sample_tag_len); sample_tag->tag_type = 0xffff; sample_tag->tag_len = sample_tag_len; sample_tag->tag_data[0]=.... ... 释放时， free(sample_tag)

是否可以用 char *tag_data 代替呢？其实它和 char *tag_data 是有很大的区别，为了说明这个问题，我写了以下的程序：例1：test_size.c 10 struct tag1 20 { 30 int a; 40 int b; 50 }__attribute ((packed)); 60 70 struct tag2 80 { 90 int a; 100 int b; 110 char *c; 120 }__attribute ((packed)); 130 140 struct tag3 150 { 160 int a; 170 int b; 180 char c[0]; 190 }__attribute ((packed)); 200 210 struct tag4 220 { 230 int a; 240 int b; 250 char c[1]; 260 }__attribute ((packed)); 270 280 int main() 290 { 300 struct tag2 l_tag2; 310 struct tag3 l_tag3; 320 struct tag4 l_tag4; 330 340 memset(&l_tag2,0,sizeof(struct tag2)); 350 memset(&l_tag3,0,sizeof(struct tag3)); 360 memset(&l_tag4,0,sizeof(struct tag4)); 370 380 printf("size of tag1 = %d\n",sizeof(struct tag1)); 390 printf("size of tag2 = %d\n",sizeof(struct tag2)); 400 printf("size of tag3 = %d\n",sizeof(struct tag3)); 410 420 printf("l_tag2 = %p,&l_tag2.c = %p,l_tag2.c = %p\n",&l_tag2,&l_tag2.c,l_tag2.c); 430 printf("l_tag3 = %p,l_tag3.c = %p\n",&l_tag3,l_tag3.c); 440 printf("l_tag4 = %p,l_tag4.c = %p\n",&l_tag4,l_tag4.c); 450 exit(0); 460 }

__attribute ((packed)) 是为了强制不进行4字节对齐，这样比较容易说明问题。程序的运行结果如下： size of tag1 = 8 size of tag2 = 12 size of tag3 = 8 size of tag4 = 9 l_tag2 = 0xbffffad0,&l_tag2.c = 0xbffffad8,l_tag2.c = (nil) l_tag3 = 0xbffffac8,l_tag3.c = 0xbffffad0 l_tag4 = 0xbffffabc,l_tag4.c = 0xbffffac4

从上面程序和运行结果可以看出：tag1本身包括两个32位整数，所以占了8个字节的空间。 tag2包括了两个32位的整数，外加一个char *的指针，所以占了12个字节。tag3才是真正看出char c[0]和char *c的区别，char c[0]中的c并不是指针，是一个偏移量，这个偏移量指向的是a、b后面紧接着的空间，所以它其实并不占用任何空间。tag4更加补充说明了这一点。所以，上面的struct pppoe_tag的最后一个成员如果 用char *tag_data定义，除了会占用多4个字节的指针变量外，用起来会比较不方便 ：

方法一，创建时，可以首先为struct pppoe_tag分配一块内存，再为tag_data分配内存，这样在释放时，要首先释放tag_data占用的内存，再释放pppoe_tag占用的内存；

方法二，创建时，直接为struct pppoe_tag分配一块struct pppoe_tag大小加上tag_data的内存，从例一的420行可以看出，tag_data的内容要进行初始化，要让tag_data指向strct pppoe_tag后面的内存。 struct pppoe_tag { __u16 tag_type; __u16 tag_len; char *tag_data; } __attribute ((packed));

struct pppoe_tag *sample_tag; __u16 sample_tag_len = 10; 方法一： sample_tag = (struct pppoe_tag *)malloc(sizeof(struct pppoe_tag)); sample_tag->tag_len = sample_tag_len; sample_tag->tag_data = malloc(sizeof(char)*sample_tag_len); sample_tag->tag_data[0]=... 释放时： free(sample_tag->tag_data); free(sample_tag);

方法二： sample_tag = (struct pppoe_tag *)malloc(sizeof(struct pppoe_tag)+sizeof(char)*sample_tag_len); sample_tag->tag_len = sample_tag_len; sample_tag->tag_data = ((char *)sample_tag)+sizeof(struct pppoe_tag); sample_tag->tag_data[0]=... 释放时： free(sample_tag); 所以无论使用那种方法，都没有char tag_data[0]这样的定义来得方便。

讲了这么多，其实本质上涉及到的是一个C语言里面的数组和指针的区别问题。char a[1]里面的a和char *b的b相同吗？《 Programming Abstractions in C》（Roberts, E. S.，机械工业出版社，2004.6）82页里面说：“arr is defined to be identical to &arr[0]”。也就是说，char a[1]里面的a实际是一个常量，等于&a[0]。而char *b是有一个实实在在的指针变量b存在。 所以，a=b是不允许的，而b=a是允许的。 两种变量都支持下标式的访问，那么对于a[0]和b[0]本质上是否有区别？我们可以通过一个例子来说明。

例二： 10 #include <stdio.h> 20 #include <stdlib.h> 30 40 int main() 50 { 60 char a[10]; 70 char *b; 80 90 a[2]=0xfe; 100 b[2]=0xfe; 110 exit(0); 120 }

编译后，用objdump可以看到它的汇编： 080483f0 <main>: 80483f0: 55 push %ebp 80483f1: 89 e5 mov %esp,%ebp 80483f3: 83 ec 18 sub

可以看出，a[2]＝0xfe是直接寻址，直接将0xfe写入&a[0]+2的地址，而b[2]=0xfe是间接寻址，先将b的内容（地址）拿出来，加2，再0xfe写入计算出来的地址。所以a[0]和b[0]本质上是不同的。

但当数组作为参数时，和指针就没有区别了。 int do1(char a[],int len); int do2(char *a,int len); 这两个函数中的a并无任何区别。都是实实在在存在的指针变量。

顺便再说一下，对于struct pppoe_tag的最后一个成员的定义是char tag_data[0]，某些编译器不支持长度为0的数组的定义，在这种情况下，只能将它定义成char tag_data[1]，使用方法相同。

总结：通过上面的转载的文章，可以清晰的发现，这种方法的优势其实就是为了简化内存的管理，我们假设在理想的内存状态下，那么分配的内存空间，可以是按序下来的（当然，实际因为内存碎片等的原因会不同的）我们可以利用最后一个数组的指针直接无间隔的跳到分配的数组缓冲区，这在LINUX下非常常见，在WINDOWS下的我只是在MFC里见过类似的，别的情况下记不清楚了，只记得MFC里的是这么讲的，可以用分配的结构体的指针直接+1。

参考文章：http://blog.csdn.net/ssdsafsdsd/article/details/8234736

转载于:https://www.cnblogs.com/Spider-spiders/p/8807760.html