Chinaunix

标题: char[0], sizeof和struct padding [打印本页]

作者: zx_wing 时间: 2009-05-17 00:26
标题: char[0], sizeof和struct padding
我想举一个自己最近在项目中犯的错误来说明要踏踏实实做人，不要做装B青年

在代码中，我需要在一个library和一个daemon之间通过socket传送数据包，包的格式定义如下（为了简化，我就用最简单的数据类型举例）：

typedef struct {
int head;
int size; //指明整个包的长度
char reply;
char data[0];
} packet;
packet* cmd = malloc (sizeof(packet) + 20);
memcpy (packet->data, some_data, 20);

复制代码

daemon将上面分配的cmd包发送给library，library接收到包后，需要将data字段中的数据取出来。size指明了整个包的长度，但没有字段指明数据的长度。我需要这么一个指明数据长度的字段吗？作为一个装B青年，我认为当然不需要，于是我这样来计算数据的长度：

#define offsetof(type, element) ((int)&((type *)0)->element)
static inline size_t packet_data_len(packet* cmd) {
assert(cmd);
return cmd->size - offsetof(packet, data);
}
memcpy (buffer_to_receive_data, cmd->data, packet_data_len (cmd));

复制代码

于是乎，这段程序成功的给我带来了无数的bug，莫名奇妙的segfault，奇怪的数据错误，还是有部分时间的正常工作。当然，最终我还是找到了问题：
sizeof (packet) == 12;
这是合理的，char reply被padding成了4个字节，而char data[0]字节为0。
但，offsetof(packet, data) == 9，在计算偏移时，char reply为一个字节，没有padding。
所以packet_data_len每次都会返回比真实的数据多3个字节 ……

最后我还是老老实实加了个data_len字段指明数据的长度，并告诫自己，本本分分写程序，莫装B ……

作者: mik 时间: 2009-05-17 00:31
我常讲的，代码的逻辑清晰要比任何小技巧要重要得多。
最简单方法就是最有效的方法。
拒绝淫技，当然 linux kernel 除外，偶不敢批

作者: edigar 时间: 2009-05-17 00:41
学习，谢谢楼主分享经验

作者: zx_wing 时间: 2009-05-17 00:47

原帖由 mik 于 2009-5-17 00:31 发表
我常讲的，代码的逻辑清晰要比任何小技巧要重要得多。
最简单方法就是最有效的方法。
拒绝淫技，当然 linux kernel 除外，偶不敢批

是的，我也从来都是这样个别人说的。
但自己却从来喜欢用些奇技淫巧，惭愧

作者: jovistar 时间: 2009-05-17 16:46
还是老老实实的比较好，起码能让逻辑看上去比较清晰明了

作者: yhb04 时间: 2009-05-17 18:08

原帖由 zx_wing 于 2009-5-17 00:26 发表
我想举一个自己最近在项目中犯的错误来说明要踏踏实实做人，不要做装B青年
在代码中，我需要在一个library和一个daemon之间通过socket传送数据包，包的格式定义如下（为了简化，我就用最简单的数据类型举例 ...

这算鸟奇技淫巧。
LZ既然用到GCC的零长数组，就应该仔细阅读结构布局的说明。显然LZ没仔细搞清楚GCC的C扩展就乱用。
要是嫌阅读说明麻烦，把最后的data[0]改成data[1]不什么事都没了嘛。

作者: baicj 时间: 2009-05-17 18:24

原帖由 yhb04 于 2009-5-17 18:08 发表

这算鸟奇技淫巧。
LZ既然用到GCC的零长数组，就应该仔细阅读结构布局的说明。显然LZ没仔细搞清楚GCC的C扩展就乱用。
要是嫌阅读说明麻烦，把最后的data[0]改成data[1]不什么事都没了嘛。

看贴不仔细, 改成data[1]不解决问题

作者: yhb04 时间: 2009-05-17 18:58

原帖由 baicj 于 2009-5-17 18:24 发表

看贴不仔细, 改成data[1]不解决问题

？？？
怎么不解决问题？说来听听。

作者: yhb04 时间: 2009-05-17 19:11
typedef struct {
      int head;
      int size; //指明整个包的长度
   char reply;
      char data[1];
} packet;

packet*  cmd = malloc (sizeof(packet) + 20); //多空几个字节无所谓
memcpy (packet->data, some_data, 20);

#define offsetof(type, element) ((unsigned long)&((type *)0)->element)
cmd->size = offsetof(packet, data) + 20;//cmd->size的计算不要用sizeof(packet)

static inline size_t packet_data_len(packet* cmd) {
assert(cmd);
return cmd->size - offsetof(packet, data);
}

memcpy (buffer_to_receive_data, cmd->data, packet_data_len (cmd));

或者直接用cmd->size记录实际数据的长度，数据在cmd->data[0]处开始。

作者: baicj 时间: 2009-05-17 19:58

原帖由 yhb04 于 2009-5-17 19:11 发表
...
#define offsetof(type, element) ((unsigned long)&((type *)0)->element)
cmd->size = offsetof(packet, data) + 20;//cmd->size的计算不要用sizeof(packet)
...

如同你所说, 问题在于daemon端用sizeof计算的struct head大小, 而library端用offsetof计算struct head大小, 两者结果不一致. 修改位data[1]不会有帮助, 解决问题的办法也正如你的代码, 统一用offsetof来代替sizeof, 或者用sizeof来代替offsetof.

作者: ilex 时间: 2009-05-17 20:24
好帖子；

一般都是不吃亏不长记性的。

就像新员工来后，很鄙视我们代码中的一些做法，认为这个那个运行效率低，

搞了几次，出了几个BUG后，就知道学乖了。

当然，楼主肯定是个老鸟，不是新员工。

作者: xman0017 时间: 2009-05-17 21:03
char data[0];

改为： char*data

应该没有问题

作者: zx_wing 时间: 2009-05-17 22:29

原帖由 yhb04 于 2009-5-17 19:11 发表
typedef struct {
      int head;
      int size; //指明整个包的长度
   char reply;
      char data[1];
} packet;

packet*  cmd = malloc (sizeof(packet) + 20); //多空几个字节无所谓
...

呵呵，小伙子水平不高口气不小。
首先char data[1]解决不了问题，char data[0]不是C标准，前者是C标准而已。
其次，gcc手册没有对零长数组有太多解释，这本来就是个简单的东西。其次这里的内存布局和是不是零长数组没有关系，把char data[0]换成char data是一样。不过你还是说对了，这是内存布局的问题引起的，具体的说着取决于padding的位置。我怀疑你是猜的，因为编译手册是不会讲这个内存布局的，不同的架构对padding有不同的规定。这个是架构的ABI或software conventions规定的。例如

struct example {
int a;
int b;
char c;
char d;
};
sizeof (struct example) == 12;
offsetof (struct example, d) == 9;

复制代码

恍然一看似乎offsetof在计算偏移的时候没有算padding，实际不然，padding在最后两个字节，所以上面例子的内存布局是：
a(4 bytes) b(4 bytes) c(1 byte) d(1 byte) padding (2 bytes)
对于我用的 x86平台，这个其在ABI手册有规定：

Each member is assigned to the lowest available offset with the appropriate
alignment. This may require internal padding, depending on the previous
member.

这里d前面的c同样是char类型，所以两者之间没有padding，而根据另一条规定：

A structure¡¯s size is increased, if necessary, to make it a multiple of the
alignment. This may require tail padding, depending on the last member.

把padding放在了最后，即tail padding。

如果有一种架构使用不同的padding方式，例如：
a(4 bytes) b(4 bytes) c(1 byte) padding (1 byte) d(1 byte) padding (1 byte)
则offsetof (struct example, d) == 10;
gcc关于零长数组的章节有点长，并且和这里的内容没有什么关系，就不贴了。我估计你也没看过，它的标题是“5.14 Arrays of Length Zero”，不信你可以去看看。

[ 本帖最后由 zx_wing 于 2009-5-17 23:15 编辑 ]

作者: mik 时间: 2009-05-17 22:50
标题: 回复 #13 zx_wing 的帖子
zx_wing 就别和他较劲了。正如你说他的：水平不高口气不小。
偶领教过，说话牛哄哄的，特拽

作者: tyc611 时间: 2009-05-17 23:17
如果是我，我会分为消息头和数据两部分

作者: zx_wing 时间: 2009-05-17 23:29

原帖由 baicj 于 2009-5-17 19:58 发表

如同你所说, 问题在于daemon端用sizeof计算的struct head大小, 而library端用offsetof计算struct head大小, 两者结果不一致. 修改位data[1]不会有帮助, 解决问题的办法也正如你的代码, 统一用offsetof来代替s ...

是的，关键问题在于offsetof和sizeof计算得来head大小不一样。
我刚才google了一下发现问这个问题的人还很多，但没人回答，下面这个帖子里的老外就以为对齐出错了：
http://connect.microsoft.com/Vis ... x?FeedbackID=253387

实际上问题仅仅是我们错误的假设的padding的位置而已。

作者: zx_wing 时间: 2009-05-17 23:31

原帖由 mik 于 2009-5-17 22:50 发表
zx_wing 就别和他较劲了。正如你说他的：水平不高口气不小。
偶领教过，说话牛哄哄的，特拽

呵呵，也不是较劲。只是借着话题顺便把问题讲清楚了，供遇到同样问题或以后遇到同样问题的朋友借鉴。

作者: yhb04 时间: 2009-05-17 23:33

原帖由 zx_wing 于 2009-5-17 22:29 发表

呵呵，小伙子水平不高口气不小。
首先char data[1]解决不了问题，char data[0]不是C标准，前者是C标准而已。
其次，gcc手册没有对零长数组有太多解释，这本来就是个简单的东西。其次这里的内存布局和是不是 ...

猜不猜不是你说了算，现在写一个C编译器也不是天方夜谈，你对结构体的布局不了解并不表示别人也这样。装B不是靠发帖数多。您爱装就继续装吧。
对了，GCC的零长数组满足不了您的需求，倒是C99 里的东西可以符合你的要求。不过现在不知道有那个编译器是些了它没有。

作者: yhb04 时间: 2009-05-17 23:38

原帖由 mik 于 2009-5-17 22:50 发表
zx_wing 就别和他较劲了。正如你说他的：水平不高口气不小。
偶领教过，说话牛哄哄的，特拽

还有你，倒是真的水平不高，口气不小。
上次花了1个小时还找了个错误的源文件

论抬杠您水平确实不赖。有个版主头衔说话就这么吊。

作者: sep 时间: 2009-05-17 23:42
学习，lz的贴都是好贴

作者: zx_wing 时间: 2009-05-17 23:42

原帖由 yhb04 于 2009-5-17 23:33 发表

猜不猜不是你说了算，现在写一个C编译器也不是天方夜谈，你对结构体的布局不了解并不表示别人也这样。装B不是靠发帖数多。您爱装就继续装吧。
对了，GCC的零长数组满足不了您的需求，倒是C99 里的东西可以符 ...

哈哈，小伙子，装B也不是靠说话拽就可以了。要像我这样，拿出大量的证据证明装的正确。
还有一点大忌就是，装之前要还是要真懂一点再装，不然像你这样稍微装一下就露马脚就丢人了。

>>你对结构体的布局不了解并不表示别人也这样
这个我确实不了解，被你说中了，我也是这次遇到问题才去查的。

这样，我给你个装的机会，我就列4种架构（我不敢列多了，我手里头只有这几种的资料），你来给我讲讲它们的结构体布局的规定（组合要全哦）。不能瞎说哦，要有证据，你可以引用你所说的编译器手册里的相关章节，我还真不知道编译器手册在什么地方讲的。

1. x86
2. x86-64
3. IA64
4. MIPS

[ 本帖最后由 zx_wing 于 2009-5-17 23:48 编辑 ]

作者: yhb04 时间: 2009-05-17 23:50

原帖由 zx_wing 于 2009-5-17 23:42 发表

哈哈，小伙子，装B也不是靠说话拽就可以了。要像我这样，拿出大量的证据证明装的正确。
还有一点大忌就是，装之前要还是要真懂一点再装，不然像你这样稍微装一下就露马脚就丢人了。

你的证据可真多呀，我没什么好说的了，拜托你把我露的马脚都指出来，让我也见识见识高手的水平啊。

作者: yhb04 时间: 2009-05-17 23:55

原帖由 zx_wing 于 2009-5-17 23:42 发表

哈哈，小伙子，装B也不是靠说话拽就可以了。要像我这样，拿出大量的证据证明装的正确。
还有一点大忌就是，装之前要还是要真懂一点再装，不然像你这样稍微装一下就露马脚就丢人了。

>>你对结构体的布局不 ...

要讲内存布局也不用扯这么多平台。
从你的第一贴就可以看出你连自己的开发平台的对齐就不清楚，扯这么多平台显得你很厉害是吧、可喜第一贴就把你自己的马脚给露了。

作者: zx_wing 时间: 2009-05-17 23:56

原帖由 yhb04 于 2009-5-17 23:50 发表

你的证据可真多呀，我没什么好说的了，拜托你把我露的马脚都指出来，让我也见识见识高手的水平啊。

哈哈，不跟你抬杠了。
你有没有马脚看了你的帖子和看了后面的回复的朋友自己会判断。

作者: zx_wing 时间: 2009-05-18 00:02

原帖由 yhb04 于 2009-5-17 23:55 发表

要讲内存布局也不用扯这么多平台。
从你的第一贴就可以看出你连自己的开发平台的对齐就不清楚，扯这么多平台显得你很厉害是吧、可喜第一贴就把你自己的马脚给露了。

你小子还真来劲了呢。本来都不想和你扯，你还起劲。
你起劲就算了，还净乱讲，新到CU的朋友看你这么牛B轰轰的嚷嚷我不说话，还以为你讲的是对的哦。最烦你这种不懂又要在这里误导人的。

>>要讲内存布局也不用扯这么多平台。
我前面已经讲了，内存布局取决于架构，在架构的ABI和software coventions中规定，你以为所有平台都一样哦。我都贴出具体的内容了你还乱讲啥。这年头，装B要讲证据，不要信口雌黄

作者: yhb04 时间: 2009-05-18 00:03

原帖由 zx_wing 于 2009-5-17 23:56 发表

哈哈，不跟你抬杠了。
你有没有马脚看了你的帖子和看了后面的回复的朋友自己会判断。

刚还说你说什么都有N出处的，现在就说我在抬杠了。你倒是指出我的那个回复露马脚。

作者: sep 时间: 2009-05-18 00:05

原帖由 yhb04 于 2009-5-18 00:03 发表

刚还说你说什么都有N出处的，现在就说我在抬杠了。你倒是指出我的那个回复露马脚。

拜托你首先用vs好，gcc好，先把自己的代码测试一下吧

作者: yhb04 时间: 2009-05-18 00:06

原帖由 zx_wing 于 2009-5-18 00:02 发表

你小子还真来劲了呢。本来都不想和你扯，你还起劲。
你起劲就算了，还净乱讲，新到CU的朋友看你这么牛B轰轰的嚷嚷我不说话，还以为你讲的是对的哦。最烦你这种不懂又要在这里误导人的。

>>要讲内存布局也 ...

那你把具体平台都贴出来好了，你贴出来吗、

作者: zx_wing 时间: 2009-05-18 00:07

原帖由 yhb04 于 2009-5-18 00:03 发表

刚还说你说什么都有N出处的，现在就说我在抬杠了。你倒是指出我的那个回复露马脚。

>>LZ既然用到GCC的零长数组，就应该仔细阅读结构布局的说明。显然LZ没仔细搞清楚GCC的C扩展就乱用。
把你说的说明给我找出来，贴到这里。我倒是孤陋寡闻不清楚编译手册什么时候会规定架构ABI管的东西

>>要是嫌阅读说明麻烦，把最后的data[0]改成data[1]不什么事都没了嘛。
给我讲讲data[1]有什么用。把内存布局画出来，证明这样改有用。

作者: mik 时间: 2009-05-18 00:08
标题: 回复 #25 zx_wing 的帖子
跟他较劲，真没必要。

我都放弃了。

你就歇歇睡吧。

作者: zx_wing 时间: 2009-05-18 00:10

原帖由 mik 于 2009-5-18 00:08 发表
跟他较劲，真没必要。

我都放弃了。

你就歇歇睡吧。

还是听你的。
我真是傻B了，还是不够淡定啊

就此打住，坚决不继续和他纠缠

作者: yhb04 时间: 2009-05-18 00:17

原帖由 zx_wing 于 2009-5-18 00:07 发表

>>LZ既然用到GCC的零长数组，就应该仔细阅读结构布局的说明。显然LZ没仔细搞清楚GCC的C扩展就乱用。
把你说的说明给我找出来，贴到这里。我倒是孤陋寡闻不清楚编译手册什么时候会规定架构ABI管的东西

>>要 ...

>>要是嫌阅读说明麻烦，把最后的data[0]改成data[1]不什么事都没了嘛。
给我讲讲data[1]有什么用。把内存布局画出来，证明这样改有用。
你要我说什么呢，按照你上面定义的结构，以X86的某个典型编译器为例，data[1]跟前面的char变量紧邻，但是整个结构的大小根据对齐原则data[0]的后面有两个字节的padding。

作者: wzw19191 时间: 2009-05-18 01:08
几位都是高手。相互争论一下也没什么不可以的，相反更有利于真相的出现。
问题弄明白目的就达到了。最重要的是我等小辈又长见识了，又能认识到自己的不足。
希望能向大佬们学习。

作者: gawk 时间: 2009-05-18 08:58
呵呵，装B被雷劈

作者: zx_wing 时间: 2009-05-18 09:07

原帖由 yhb04 于 2009-5-18 00:17 发表

>>要是嫌阅读说明麻烦，把最后的data[0]改成data[1]不什么事都没了嘛。
给我讲讲data[1]有什么用。把内存布局画出来，证明这样改有用。
你要我说什么呢，按照你上面定义的结构，以X86的某个典型编译器为例， ...

呵呵，data[0]也和前面的紧邻的
如果仅仅是malloc(sizeof(packet))，则data[1]情况变为：
head (4 bytes) size (4 bytes) reply (1 byte) data[1] (1 bytes) padding (2 bytes)
如果是data[0]：
head (4 bytes) size (4 bytes) reply (1 byte) data[0] (0 bytes) padding (3 bytes)

不管data[0]，data[1]，malloc(sizeof(packet) + 20)后，之后都没有padding。所以两者内存布局本质是一样的，把data[0]改成data[1]没有任何帮助。

你跟我讲技术，我就心平气和的给你讲

[ 本帖最后由 zx_wing 于 2009-5-18 09:12 编辑 ]

作者: yhb04 时间: 2009-05-18 09:55

原帖由 zx_wing 于 2009-5-18 09:07 发表

呵呵，data[0]也和前面的紧邻的
如果仅仅是malloc(sizeof(packet))，则data[1]情况变为：
head (4 bytes) size (4 bytes) reply (1 byte) data[1] (1 bytes) padding (2 bytes)
如果是data[0]：
head (4 ...

谁说内存内存布局不一样了，只是改成data[1]啥的就可以正确求的offset(data,packet)的值了。
gcc的data[0]的实现就比较诡异了，实际应用中用这个东西是为了应付变长结构，这个时候使用sizeof(packet)是不适宜的，因为它考虑了结构末尾的padding。
我本来说了C99里面的data[]满足你的要求。

C99：
16 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. With two
exceptions, the flexible array member is ignored. First, the size of the structure shall be
equal to the offset of the last element of an otherwise identical structure that replaces the
flexible array member with an array of unspecified length.106) Second, when a . (or ->)
operator has a left operand that is (a pointer to) a structure with a flexible array member
and the right operand names that member, it behaves as if that member were replaced
with the longest array (with the same element type) that would not make the structure
larger than the object being accessed; the offset of the array shall remain that of the
flexible array member, even if this would differ from that of the replacement array. If this
array would have no elements, it behaves as if it had one element but the behavior is
undefined if any attempt is made to access that element or to generate a pointer one past
it.
17 EXAMPLE Assuming that all array members are aligned the same, after the declarations:
struct s { int n; double d[]; };
struct ss { int n; double d[1]; };
the three expressions:
sizeof (struct s)
offsetof(struct s, d)
offsetof(struct ss, d)
have the same value. The structure struct s has a flexible array member d.

PS：如果你不和俺抬杠，俺也可以心平气和的和你谈。

作者: yhb04 时间: 2009-05-18 09:59
标题: 回复 #35 zx_wing 的帖子
还有，这个问题本身跟各个平台的ABI没有太大关系。
我只假设你在X86平台上用gcc编译2个程序，互相通信。
如果你说你的一个程序是X86的gcc编译的程序，另一个是其他平台其他编译器编译的程序。那当我前面什么都没说。

作者: zx_wing 时间: 2009-05-18 10:03

原帖由 yhb04 于 2009-5-18 09:55 发表

谁说内存内存布局不一样了，只是改成data[1]啥的就可以正确求的offset(data,packet)的值了。
gcc的data[0]的实现就比较诡异了，实际应用中用这个东西是为了应付变长结构，这个时候使用sizeof(packet)是不适宜 ...

》》只是改成data[1]啥的就可以正确求的offset(data,packet)的值了、
data[0],data[1]通过offsetof求值是一样的，因为它们之前的内存布局相同

作者: zx_wing 时间: 2009-05-18 10:04

原帖由 yhb04 于 2009-5-18 09:59 发表
还有，这个问题本身跟各个平台的ABI没有太大关系。
我只假设你在X86平台上用gcc编译2个程序，互相通信。
如果你说你的一个程序是X86的gcc编译的程序，另一个是其他平台其他编译器编译的程序。那当我前面什么都 ...

当然有关系。如果ABI规定padding在reply之后data之前，结果就完全不一样

作者: yhb04 时间: 2009-05-18 10:05

原帖由 zx_wing 于 2009-5-18 10:03 发表

》》只是改成data[1]啥的就可以正确求的offset(data,packet)的值了、
data[0],data[1]通过offsetof求值是一样的，因为它们之前的内存布局相同

typedef struct {
      int head;
      int size; //指明整个包的长度
   char reply;
      char data[1];
} packet;

packet*  cmd = malloc (sizeof(packet) + 20); //多空几个字节无所谓
memcpy (packet->data, some_data, 20);

#define offsetof(type, element) ((unsigned long)&((type *)0)->element)
cmd->size = offsetof(packet, data) + 20;//cmd->size的计算不要用sizeof(packet)

static inline size_t packet_data_len(packet* cmd) {
assert(cmd);
return cmd->size - offsetof(packet, data);
}

memcpy (buffer_to_receive_data, cmd->data, packet_data_len (cmd));

或者直接用cmd->size记录实际数据的长度，数据在cmd->data[0]处开始。

作者: yhb04 时间: 2009-05-18 10:06

原帖由 zx_wing 于 2009-5-18 10:04 发表

当然有关系。如果ABI规定padding在reply之后data之前，结果就完全不一样

据我所知，结构体内的域之间的padding不是ABI规定的，而是编译器的具体实现。

C89：
Each non-bit-field member of a structure or union object is aligned
in an implementation-defined manner appropriate to its type.

Within a structure object, the non-bit-field members and the units
in which bit-fields reside have addresses that increase in the order
in which they are declared.  A pointer to a structure object, suitably
cast, points to its initial member (or if that member is a bit-field,
then to the unit in which it resides), and vice versa.  There may
therefore be unnamed holes within a structure object, but not at its
beginning, as necessary to achieve the appropriate alignment.

The size of a union is sufficient to contain the largest of its
members.  The value of at most one of the members can be stored in a
union object at any time.  A pointer to a union object, suitably cast,
points to each of its members (or if a member is a bit-field, then to
the unit in which it resides), and vice versa.

There may also be unnamed padding at the end of a structure or
union, as necessary to achieve the appropriate alignment were the
structure or union to be a member of an array.

作者: zx_wing 时间: 2009-05-18 10:10

原帖由 yhb04 于 2009-5-18 10:06 发表

据我所知，结构体内的域之间的padding不是ABI规定的，而是编译器的具体实现。

C89：
Each non-bit-field member of a structure or union object is aligned
in an implementation-defined manner appro ...

嗯，现在像讲技术的态度了。
implementation-defined manner，确实是编译具体实现，但编译器的具体实现遵照的就是架构ABI。不论是编译器还是操作系统，都是必须遵照它。
implementation-defined manner 指就是对于不同的架构其实现可能不一样，因为架构的ABI不一样。

作者: yhb04 时间: 2009-05-18 10:13

原帖由 zx_wing 于 2009-5-18 10:10 发表

嗯，现在像讲技术的态度了。
implementation-defined manner，确实是编译具体实现，但编译器的具体实现遵照的就是架构ABI。不论是编译器还是操作系统，都是必须遵照它。
implementation-defined manner 指就 ...

ABI主要控制的是操作系统与应用程序的系统调用的惯例，虽然在系统调用中如果传结构体参数，那么结构体必须遵照OS的ABI来控制padding，但是这并不是强制的。

作者: zx_wing 时间: 2009-05-18 10:14

原帖由 yhb04 于 2009-5-18 10:05 发表

typedef struct {
      int head;
      int size; //指明整个包的长度
   char reply;
      char data[1];
} packet;

packet*  cmd = malloc (sizeof(packet) + 20); //多空几个字节无所谓 ...

你这样改之所以对，不是因为把data[0]改成data[1]了，10楼就已经指出了原因

如同你所说, 问题在于daemon端用sizeof计算的struct head大小, 而library端用offsetof计算struct head大小, 两者结果不一致. 修改位data[1]不会有帮助, 解决问题的办法也正如你的代码, 统一用offsetof来代替sizeof, 或者用sizeof来代替offsetof.

所以即使是data[0]也是一样。

此外要改的彻底,packet* cmd = malloc (sizeof(packet) + 20);直接改成packet* cmd = malloc (offsetof(packet, data) + 20);

作者: yhb04 时间: 2009-05-18 10:15

原帖由 zx_wing 于 2009-5-18 10:10 发表

嗯，现在像讲技术的态度了。
implementation-defined manner，确实是编译具体实现，但编译器的具体实现遵照的就是架构ABI。不论是编译器还是操作系统，都是必须遵照它。
implementation-defined manner 指就 ...

还有，我前面的代码能否解决你的问题？

作者: zx_wing 时间: 2009-05-18 10:15

原帖由 yhb04 于 2009-5-18 10:13 发表

ABI主要控制的是操作系统与应用程序的系统调用的惯例，虽然在系统调用中如果传结构体参数，那么结构体必须遵照OS的ABI来控制padding，但是这并不是强制的。

呵呵，该讲的我都讲了。
你也可以到编译器版发贴求证我说的是否正确。

作者: yhb04 时间: 2009-05-18 10:17
标题: 回复 #44 zx_wing 的帖子
所以即使是data[0]也是一样。

此外要改的彻底,packet* cmd = malloc (sizeof(packet) + 20);直接改成packet* cmd = malloc (offsetof(packet, data) + 20);

没错啊，我本来就是这个意思，gcc的data[0]的结构体的sizeof很诡异，就不应该用sizeof。

作者: Beetle-K-V 时间: 2009-05-18 10:20
一群疯子，个个都把自己当个玩意。

作者: poxma 时间: 2009-05-18 11:01
标题: 附带问个问题
如果要发个数据包
格式就像下面这个结构一样
typedef struct {
      int head;
      int size;
   char reply;
      char data[0];
} packet;
遇到发送端和接收端的int类型大小不同怎么办啊

作者: yulc 时间: 2009-05-18 11:29

原帖由 zx_wing 于 2009-5-17 00:26 发表
我想举一个自己最近在项目中犯的错误来说明要踏踏实实做人，不要做装B青年
在代码中，我需要在一个library和一个daemon之间通过socket传送数据包，包的格式定义如下（为了简化，我就用最简单的数据类型举例 ...

得好复杂,你把结构体改为:
typedef struct {
      int head;
      int size; //指明整个包的长度
   char reply;
      char pad[3]; // 补齐
      char data[0];
} packet;

就OK了呀.

作者: ShadowStar 时间: 2009-05-18 12:32

原帖由 zx_wing 于 2009-5-17 00:26 发表
我想举一个自己最近在项目中犯的错误来说明要踏踏实实做人，不要做装B青年
在代码中，我需要在一个library和一个daemon之间通过socket传送数据包，包的格式定义如下（为了简化，我就用最简单的数据类型举例 ...

其实，我觉得，LZ把

typedef struct {
int head;
int size; //指明整个包的长度
char reply;
char data[0];
} packet;

复制代码

改为

typedef struct {
struct {
int head;
int size; //指明整个包的长度
char reply;
};
char data[0];
} packet;

复制代码

就OK了。

作者: kouu 时间: 2009-05-18 13:15
LZ的帖子不是做经验分享的么？怎么好多人理解成求助帖了…… 搞不懂

作者: FeCen 时间: 2009-05-18 13:28

原帖由 tyc611 于 2009-5-17 23:17 发表
如果是我，我会分为消息头和数据两部分

原帖由 ShadowStar 于 2009-5-18 12:32 发表

其实，我觉得，LZ把typedef struct {
      int head;
      int size; //指明整个包的长度
      char reply;
      char data[0];
} packet;

改为typedef struct {
struct {
      i ...

我觉得以上两位说的挺有道理的，呵呵。

作者: 思一克 时间: 2009-05-18 13:42

是找到了问题：
sizeof (packet) == 12;
这是合理的，char reply被padding成了4个字节，而char data[0]字节为0。
但，offsetof(packet, data) == 9，在计算偏移时，char reply为一个字节，没有padding。
所以packet_data_len每次都会返回比真实的数据多3个字节 ……

----------------------------
LZ分析的不对。
offsetof(packet, data)=9 说明没有将reply padding为4个字节。

作者: zx_wing 时间: 2009-05-18 13:51

原帖由 思一克 于 2009-5-18 13:42 发表

----------------------------
LZ分析的不对。
offsetof(packet, data)=9 说明没有将reply padding为4个字节。

我在35楼已经讲了这个padding什么时候发生什么时候不发生

呵呵，data[0]也和前面的紧邻的
如果仅仅是malloc(sizeof(packet))，则data[1]情况变为：
head (4 bytes) size (4 bytes) reply (1 byte) data[1] (1 bytes) padding (2 bytes)
如果是data[0]：
head (4 bytes) size (4 bytes) reply (1 byte) data[0] (0 bytes) padding (3 bytes)

不管data[0]，data[1]，malloc(sizeof(packet) + 20)后，之后都没有padding。所以两者内存布局本质是一样的，把data[0]改成data[1]没有任何帮助。

作者: 思一克 时间: 2009-05-18 13:55

原帖由 zx_wing 于 2009-5-18 13:51 发表

我在35楼已经讲了这个padding什么时候发生什么时候不发生

知道了。
反正，你根据offsetof（data)的数值，如果是9，前面的char reply就无padding。就是紧密的。
如果是12, 就是有。

作者: converse 时间: 2009-05-18 14:33

原帖由 ShadowStar 于 2009-5-18 12:32 发表

其实，我觉得，LZ把typedef struct {
      int head;
      int size; //指明整个包的长度
      char reply;
      char data[0];
} packet;

改为typedef struct {
struct {
      i ...

支持这种做法,单独把包头独立出来定义成一个结构体逻辑上也是正确的,这种做法最好不过了.

作者: zx_wing 时间: 2009-05-18 14:44

原帖由 converse 于 2009-5-18 14:33 发表

支持这种做法,单独把包头独立出来定义成一个结构体逻辑上也是正确的,这种做法最好不过了.

前面的定义主要是想说明问题而简化的，实际我的定义中间也嵌套了多个struct，

struct sf_packet_cmd {
sf_packet_head_t head;
sf_cmd_t cmd;
bool_t is_reply;
char data[0];
};

复制代码

问题是data前面还有一个变量。除非包装到完全把data独立出来。
写这篇帖子的目的主要是想说明最好还是不要写可能涉及到padding格式的代码，可能在x86下没问题了，换个平台又出问题了。哈哈，算个教训吧。

作者: darkerwc2 时间: 2009-05-19 01:31

了解了。

作者: erwin1984 时间: 2009-05-19 10:25
在网络数据传输的情况我一般使用 #pragma pack(1) ... #pragma pack()，也挺省事的。

作者: guoruimin 时间: 2009-05-19 10:26
不会用，应该搞清楚该怎么用。
而不是，用一种愚蠢的方法解决，误导大家。

作者: eexplorer 时间: 2009-05-19 13:48

原帖由 zx_wing 于 2009-5-17 00:26 发表
我想举一个自己最近在项目中犯的错误来说明要踏踏实实做人，不要做装B青年
在代码中，我需要在一个library和一个daemon之间通过socket传送数据包，包的格式定义如下（为了简化，我就用最简单的数据类型举例 ...

涉及到［0］，网络数据交换，一般都需要__attribute__((packed)).

作者: landylau_ren 时间: 2009-05-19 13:59

很naive的一个错误啊有必要花我这么长时间去看一堆乱七八糟的讨论
少点争论，有事说事
我还以为有什么高深的技术含量咧
真是个装13问题

作者: zx_wing 时间: 2009-05-19 14:01

原帖由 eexplorer 于 2009-5-19 13:48 发表

涉及到［0］，网络数据交换，一般都需要__attribute__((packed)).

>>__attribute__((packed))
是的，这个是应该的

作者: zx_wing 时间: 2009-05-19 14:02

原帖由 landylau_ren 于 2009-5-19 13:59 发表

很naive的一个错误啊有必要花我这么长时间去看一堆乱七八糟的讨论
少点争论，有事说事
我还以为有什么高深的技术含量咧
真是个装13问题

哈哈，错误是很naive。
光看个sizeof != offsetof确实也没什么技术含量

作者: fly6 时间: 2009-05-19 15:13
在网络数据传输的情况我一般使用 #pragma pack(1) ... #pragma pack()，也挺省事的。
============================
我用的就是这种方法,楼主是什么方法解决的

作者: OwnWaterloo 时间: 2009-05-19 16:23

原帖由 erwin1984 于 2009-5-19 10:25 发表
在网络数据传输的情况我一般使用 #pragma pack(1) ... #pragma pack()，也挺省事的。

使用#pragma pack或者 __attribute__((packed))是解决了padding问题。
但是会不会导致新的，未对齐数据访问的问题？

作者: zx_wing 时间: 2009-05-19 16:27

原帖由 OwnWaterloo 于 2009-5-19 16:23 发表

使用#pragma pack或者 __attribute__((packed))是解决了padding问题。
但是会不会导致新的，未对齐数据访问的问题？

在代码中避免使用类似：
*(int*)&a_struct->member = xxx;
的方式，使用memcpy

作者: OwnWaterloo 时间: 2009-05-19 16:31
标题: 回复 #68 zx_wing 的帖子
ok，又是效率问题了 ……

其实并不是使用memcpy的时候，而是在写下 packed 的时候，效率问题就挥之不去了 ……
解决方法还是像楼主所说的那样 ……
一开始就“踏踏实实”写代码~~~ 尽可能少玩"花招"~~~

[ 本帖最后由 OwnWaterloo 于 2009-5-19 16:36 编辑 ]

作者: coneagoe 时间: 2009-05-20 08:04
mark一下，提醒自己

作者: wsw1wsw2 时间: 2009-05-20 15:50
#define offsetof(type, element) ((unsigned long)&((type *)0)->element)
==================================
类似这种东西，真的是不敢苟同。Linux Kernel 中的代码我就当看个西洋镜，自己做软件的时候用这种“技巧”不会把自己绕死啊。

针对LZ对数据结构的设计，特别是要与其他进程通讯的数据结构，千万不要省下我们自以为可以省下的信息。

有的时候看人家程序员的代码，感觉很幼稚，++ , -- 的操作做的都十分谨慎，但是程序设计多了，反而发现自己很幼稚。

作者: peimichael 时间: 2009-05-20 16:23
学习了，我自己对padding理解的也一直比较模糊。

这句话有气魄
作为一个装B青年，我认为当然不需要

作者: flyingtime 时间: 2009-05-21 13:59

好贴，顶起

作者: yeehya 时间: 2009-05-21 14:30
其实对于网络传输,为什么不用pragma pack,不是标准?

作者: SanZhiYuan 时间: 2009-05-21 14:34
求问下那段宏到底罗嗦的什么东西？我用gcc没编译通过

error: cast from 'char (*)[0]' to 'int' loses precision

作者: OwnWaterloo 时间: 2009-05-21 15:53
标题: 回复 #75 SanZhiYuan 的帖子
将指针转型到整数会丢失精度。

作者: ryan3216 时间: 2009-05-21 21:32
提示: 作者被禁止或删除内容自动屏蔽

作者: jamesr 时间: 2009-05-25 17:43
提示: 作者被禁止或删除内容自动屏蔽

作者: syno_snow 时间: 2009-05-26 11:58
学习了，就事论事的讨论很吸引人:wink:

作者: 雨过白鹭洲 时间: 2009-05-27 00:29
不同机器间的数据交换，除了对齐，还有大端小端等等问题

你定义struct来传报文，当然会出问题了；传二进制数据也同样是不可靠的

感谢楼主分享经验。。

作者: xiaoQ008 时间: 2009-05-27 02:20
提示: 作者被禁止或删除内容自动屏蔽

作者: lbaby 时间: 2009-06-14 21:47
网络间传递raw bin 数据，只能说这个想法太让人无语了。

作者: lbaby 时间: 2009-06-14 21:54

原帖由 雨过白鹭洲 于 2009-5-27 00:29 发表
不同机器间的数据交换，除了对齐，还有大端小端等等问题

你定义struct来传报文，当然会出问题了；传二进制数据也同样是不可靠的

感谢楼主分享经验。。

还是这位兄弟，是解决问题的人，要解决问题，就要学此位兄弟的态度

作者: xhl 时间: 2009-06-14 23:00
很典型的把简单的问题复杂化。

无聊贴。

作者: glq2000 时间: 2010-07-15 20:43

得好复杂,你把结构体改为:
typedef struct {
int head;
int size; //指明整个包的长 ...
yulc 发表于 2009-05-18 11:29

恩这个加char pad[3]的办法在当前环境下是可行的，但它针对的是特定的补齐方案，万一int占8个字节呢？那就要改为char pad[7]了么。。。。。。。。。

作者: jssfy 时间: 2010-07-15 22:26

呵呵，小伙子水平不高口气不小。
首先char data[1]解决不了问题，char data[0]不是C标准，前者是C标准而 ...
zx_wing 发表于 2009-05-17 22:29

长见识了，今天才知道有gcc manual这个东东

作者: 没本 时间: 2010-07-15 23:53
问题不是出在 char data[0]上，因对struct的理解不到位，程序出问题而不敢再用 char data[0]并不能实际解决问题。

作者: axengine 时间: 2011-11-26 14:34

我想举一个自己最近在项目中犯的错误来说明要踏踏实实做人，不要做装B青年
在代码中，我需要在一个libr ...
zx_wing 发表于 2009-05-17 00:26

为什么不
#pragma pack(1) 一字节对齐呢？？？？？？？？？？？？

作者: chenyoufu123 时间: 2011-11-28 16:26
好多开源软件以及内核中都大量使用了data【0】的技巧，所以一定要学会怎么用

欢迎光临 Chinaunix (http://bbs.chinaunix.net/)