大小端模式編程陷阱：跨平台移植的血淚教訓

前言：看不見的兼容性殺手

x86 架構普遍採用小端模式，而 PowerPC 等處理器可配置為大端或小端。代碼在舊板卡（小端）運行完美，換到新板卡（大端）卻莫名其妙報錯，且極難調試——因為開發者往往根本不會懷疑是字節序問題。

實戰案例：I2C 寄存器地址傳遞錯誤

問題代碼

void i2c_write(..., unsigned char *reg, ...); // reg 為寄存器地址指針

// 調用處
int cTest = 2;
i2c_write(..., (unsigned char *)&cTest, ...);

小端模式下（舊板 Simba，MPC8572）

int cTest = 2，內存佈局（低地址→高地址）：02 00 00 00。
(unsigned char *)&cTest 取得的是最低地址，即 0x02 所在位置，傳遞正確。

大端模式下（新板 Tembo，P4080）

同樣 cTest = 2，內存佈局：00 00 00 02。
(unsigned char *)&cTest 仍取最低地址，但此時該位置存儲的是 0x00（最高有效位），導致寄存器地址錯誤，通信失敗。

根因分析：C 標準與編程習慣

• 標準規定：(unsigned char *)&cTest 必須指向該對象佔用內存區域的起始地址（最低地址），與大小端無關。
• 核心錯誤：假設 int 的低位字節一定在起始地址，這只在小端成立。大端下起始地址存的是高位字節。
• 類型不匹配：函數期望 unsigned char *（單字節地址），卻強行轉換 int *，違反嚴格別名規則，行為未定義。

最佳實踐：消除假設，嚴格類型

1. 參數類型精確匹配：需要什麼類型，就定義什麼類型的變量。若函數要 unsigned char，就聲明 unsigned char reg = 0x02; 並傳 ®。
2. 明確 signed/unsigned：不要假設 char 是否帶符號，顯式使用 signed char 或 unsigned char。
3. 跨平台數據交換：網絡傳輸、文件存儲、硬件寄存器操作均應顯式處理字節序（如 htonl/ntohl 或手動移位），不可依賴宿主字節序。
4. 編譯器屬性：GCC/Clang 可用 __attribute__((packed, aligned)) 控制結構體佈局，但不能改變基本類型的字節序。

總結

這個「小問題」耗時數天排查，根源在於隨意的類型轉換與隱含的大小端假設。嚴格的類型系統思維、顯式的字節序處理、拒絕「碰巧能跑」的代碼，是跨平台 C 編程的生存法則。