你就问同事一个问题，两级结构都是动态的，那他申请内存的长度，要怎么确定？sizeof那个结构还要不要乘，乘的话就看不对了，不乘的话又何必。
【 在 flyren911 的大作中提到: 】
: 今天同事因为这个事差点吵起来了，事情是这样的：
: 两个process之间通过信号通信，A发了一个动态信号给B，B需要用一个静态数据结构保存下来在本地处理。信号数据结构简化了一下，看起来像这样，portCap的长度是动态的，band的长度也是动态的。
: typedef struct bandType
: ...................
--
FROM 115.192.110.*

你问得这个问题
楼主的结构也处理不了

他的方式比对方好
但是也没用到变长结构的优点

【 在 webhost 的大作中提到: 】
: 你就问同事一个问题，两级结构都是动态的，那他申请内存的长度，要怎么确定？sizeof那个结构还要不要乘，乘的话就看不对了，不乘的话又何必。
--
FROM 118.199.90.*

两个比较的话，楼主的稍好一些。后者确实容易误导。    但前面的的定义xxx[1]也很容易误导，我来做的话，会将数据头和内容分开定义，或者，编译器支持的话，用零长度数组。
--
FROM 180.166.53.*

楼主的是char data[MAX_LEN];  
只要MAX_LEN能保证比双方协商的最大数据字节更大就行了，一次malloc即可，至于data里具体数据就留着慢慢解析。
他同事那个portCapT portCap[MAX_NUM];
算什么？就算MAX_NUM比双方协商的可能最多的portCapT数量更大，然而每个portCapT结构里的bandTypeT又是变长的，所以这个结构直接申请，肯定内存不够。为了让内存够，那个MAX_NUM实际上必须等于MAX_LEN/sizeof(bandTypeT)，然而这样转一道又何必呢？不如楼主直接规定最大字节来的简单明了。而且像楼主说的，那个可变数组的下标，取过来之后，内存不是内存，指针又不是指针，就是给维护的人挖坑啊。

【 在 slowaction 的大作中提到: 】
: 你问得这个问题
: 楼主的结构也处理不了
: 他的方式比对方好
: ...................
--
FROM 115.192.110.*

接收信号的实现我们不管，是操作系统的功能。嵌入式系统，发送和接收就是同一块内存的所有者的变更，所以一般情况下是不会有保存在本地的需求的。接收到信号后进行处理，处理完后释放。

【 在 slowaction 的大作中提到: 】
你没有len
那你的传输部分和解析部分就是绑死的
你必须一边解析一边接受
否则你都不知道一个包什么时候结束

你这必然造


- 来自 水木社区APP v3.4.4
--
FROM 39.144.137.*