作者：microsun
平時大家接觸最多的可能是X86平臺，在這種系統上寫程序幾乎不需要考慮太多問題，但ARM上就不一樣了，最常見也最容易被忽略的問題可能就是字節的對齊，即使像我這樣有六七年程序開發經驗的才手也時常難于提防，最近就有一個BUG，花了一天時間最終發現是對齊引發的，在此與大家分享，但愿大家能夠注意到。
我在EBOOT中讀取存在HARD DISK上的nk.bin文件，從而從HARD DISK上LOAD WINCE系統，在這個過程中總是有check sum錯誤，但從ethernet下載時不會有錯，所以問題應該還是在我加的這部分代碼上，而且同樣的代碼在PC上能正常運行。經過檢查代碼的邏輯關系是正確的。接著我在出錯時將那些數據全部用調試信息打出來，發現從文件開始算起第4096個字節被丟掉了，而其它的字節都是對的。初步判斷是對齊引發的問題，所以去查每一個BUFFER，最終發現是在讀取硬盤數據時BUFFERR并沒有按雙字節對齊，而硬盤以16BIT讀取數據，而引發了錯誤。
實際上，這類問題在ARM系統上很常見，讓人防不勝防，以下是我的一些例子。
1，解析數據流時應該時刻注意。如果需要把一個數據流（BUFFER）轉化成結構進行取值，就應該把這個結構定義為按字節存取.考慮如下結構：
struct a{
char a;
short b;
long c;
};
如果某個數據流中包含這樣的結構，而且我們要直接將數據流的指針轉化成該結構的指針，然后直接取結構成員的值，我們就應該將這個結構定義成按字節訪問，即將其夾在語句
#pragma pack(push,1)
...
#pragma pack(pop)
之中。如果我們不這樣做，編譯器會將成員b的地址對齊到short指針的地址，即在a之后加上一個char即8位的成員，將C對齊到LONG，即在B之后再加一個char成員。如此一來，成員B和成員C就得不到正確的值了。
如果我們定義一個普通的結構用來存放一些數據，則不用定義成按字節存取，編譯器會加上一些占位成員，但并不會影響程序的運行。從這個意義上講，在ARM中，將結構成員定義成CHAR和SHORT來節約內存是沒有意義的。
一個典型的例子就文件系統的驅動程序，文件是以一些已經定義好的結構存放在存儲介質上的，它們被讀取到一個BUFFER中，而具體取某個文件、目錄結構時，我們會將地址轉化成結構而讀取其中的值。
2，訪問外設時。
例如，磁盤驅動通常以16BIT的方式存取數據，即每次存取兩個字節，這樣就要求傳給它的BUFFER是雙字節對齊的，驅動程序應該至上層傳來的指針做出正確的處理以保證數據的正確性。
3.有時，我們沒有將數據流指針轉化為結構指針取值，但如果我們讀取的是雙字節或者是四字節的數據，同樣需要注意對齊的問題，例如，如果從一個BUFFER的偏移10處讀取一個四字節值，則實際得到的值是偏移8處的
地址上的DWORD值。