char[0], sizeof和struct padding

guoruimin

不会用，应该搞清楚该怎么用。
而不是，用一种愚蠢的方法解决，误导大家。

eexplorer

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

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

landylau_ren

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

zx_wing

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


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

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

zx_wing

原帖由 landylau_ren 于 2009-5-19 13:59 发表
  
很naive的一个错误啊  有必要花我这么长时间去看一堆乱七八糟的讨论  
少点争论，有事说事
我还以为有什么高深的技术含量咧
真是个装13问题

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

fly6

在网络数据传输的情况我一般使用 #pragma pack(1) ... #pragma pack()， 也挺省事的。
============================
我用的就是这种方法,楼主是什么方法解决的

OwnWaterloo

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

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

zx_wing

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


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

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

OwnWaterloo

ok， 又是效率问题了 ……

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

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

coneagoe

mark一下，提醒自己