最近在搞個網(wǎng)絡(luò)通信協(xié)議,采用socket udp傳輸,運行時,居然報段錯誤了,經(jīng)過debug,發(fā)現(xiàn)居然是因為字節(jié)對齊問題導(dǎo)致的。
這個問題在實現(xiàn)通信協(xié)議,是經(jīng)常會遇到的問題,為了方便讀者理解,我把內(nèi)容做了簡化,分享給大家。
1、協(xié)議說明
通信協(xié)議信令格式如下:
typedef?struct?protocol_msg_s{
?UINT8?msgType;
?UINT8?data1;
?UINT8?data2;
?UINT16?len;
?char?data[100];
}PRO_MSG;
根據(jù)協(xié)議格式,我造了一個數(shù)據(jù)frm,代表我收到的某個信令,
?UCHAR?frm[]={0x12,0x34,0x56,0x00,0x07,0x01,0x02,0x03,0x04,0x05,0x06,0x07};
根據(jù)協(xié)議,信令的字段與原始幀對應(yīng)關(guān)系如下
于是我實現(xiàn)了一個簡單的解析代碼【該代碼有問題】
int?main(int?argc,?char?**argv)
{
?int?ret;
?int?frm_len?=?0;
?UINT8?frm[]={0x12,0x34,0x56,0x00,0x07,0x01,0x02,0x03,0x04,0x05,0x06,0x07};
?PRO_MSG?*pmsg?=?(PRO_MSG?*)frm;
?printf("devType:%02x?data1:%02x?data2:%02x?len:%04x?n",
???pmsg->msgType,
???pmsg->data1,
???pmsg->data2,
???pmsg->len);
}
編譯運行后,其中l(wèi)en的值居然是0107,而不是0007
這其實就是因為編譯器采用了字節(jié)對齊導(dǎo)致的,
在給pmsg->len賦值時,因為需要2個字節(jié),
這兩個字節(jié)是frm[3]、frm[4]這正好分布在兩個字里,
編譯器忽略了frm[3],最終將frm[4]、frm[5]合在一起賦值給了pmsg->len
為什么有字節(jié)對齊?
簡單的說內(nèi)存對齊能夠提高 cpu 讀取數(shù)據(jù)的速度,減少 cpu 訪問數(shù)據(jù)的出錯性(有些 cpu 必須內(nèi)存對齊,否則指針訪問會出錯)。
原因找打了,下面就是解決了。
2、解決辦法
1. 方法1 #pragma pack()
該預(yù)處理指令用來改變對齊參數(shù)。在缺省情況下,C編譯器為每一個變量或數(shù)據(jù)單元按其自然對界條件分配空間。一般地,可以通過下面的方法來改變?nèi)笔〉膶R參數(shù):
使用偽指令#pragma?pack?(n),C編譯器將按照n字節(jié)對齊。
使用偽指令#pragma?pack?(),取消自定義字節(jié)對齊方式。
完整代碼
#include?<stdio.h>
#include?<string.h>
typedef?unsigned?char?UINT8;
typedef?unsigned?short?UINT16;
#define?MAX_FRM_DATA_LEN?100
#pragma?pack(1)
typedef?struct?protocol_msg_s{
?UINT8?msgType;
?UINT8?data1;
?UINT8?data2;
?UINT16?len;
?char?data[MAX_FRM_DATA_LEN];
}PRO_MSG;
#pragma
int?main(int?argc,?char?**argv)
{
?int?ret;
?int?frm_len?=?0;
?UINT8?frm[]={0x12,0x34,0x56,0x00,0x07,0x01,0x02,0x03,0x04,0x05,0x06,0x07};
?PRO_MSG?*pmsg?=?(PRO_MSG?*)frm;
?printf("devType:%02x?data1:%02x?data2:%02x?len:%04x?n",
???pmsg->msgType,
???pmsg->data1,
???pmsg->data2,
???pmsg->len);
}
2. 方法2
老老實實將收到的數(shù)據(jù)幀逐字節(jié)解析,
并填充到struct protocol_msg_s
#include?<stdio.h>
#include?<string.h>
typedef?unsigned?char?UINT8;
typedef?unsigned?short?UINT16;
#define?MAX_FRM_DATA_LEN?100
typedef?struct?protocol_msg_s{
?UINT8?msgType;
?UINT8?data1;
?UINT8?data2;
?UINT16?len;
?char?data[MAX_FRM_DATA_LEN];
}PRO_MSG;
int?frm_parse(PRO_MSG?*pmsg,UINT8?buf[],int?len)
{
?int?pos=0;
?pmsg->msgType?=?buf[pos];
?pos++;
?pmsg->data1?=?buf[pos];
?pos++;?
?pmsg->data2?=?buf[pos];
?pos++;
?pmsg->len?=?buf[pos]<<8?|?buf[pos+1]<<0;
?pos+=2;?
?if(pmsg->len>MAX_FRM_DATA_LEN)
?{
??printf("frm?len?is?longer?than?100n");
??return?-1;
?}
?memcpy(pmsg->data,&buf[pos],pmsg->len);
?return?0;
}
int?maini(int?argc,?char?**argv)
{
?int?ret;
?int?frm_len?=?0;
?UINT8?frm[]={0x12,0x34,0x56,0x00,0x07,0x01,0x02,0x03,0x04,0x05,0x06,0x07};
?PRO_MSG?msg;
?PRO_MSG?*pmsg?=?&msg;
?frm_len?=?sizeof(frm);
?ret?=?frm_parse(pmsg,frm,frm_len);
?if(ret<0)
?{
??printf("frm_parse?failn");
??return?-1;
?}
?printf("devType:%02x?data1:%02x?data2:%02x?len:%04x?n",
???pmsg->msgType,
???pmsg->data1,
???pmsg->data2,
???pmsg->len);
?return?0;
}