內存比較與字節對齊陷阱：為什麼 long* 掃描 4K buffer 可能崩潰

前言

某技術博客提出「用 `long*` 掃描 4K buffer 判斷全零比 `memcmp` 快 3 倍」，實測確實更快。但**直接將任意 `char*` 強轉為 `long*` 解引用在嚴格對齊架構 (SPARC, ARMv7, MIPS) 上會觸發 SIGBUS 崩潰**。本文分析對齊陷阱，給出安全、高效、可移植的解決方案。

危險代碼 (博客原版)

long* wp = (long*)buffer;  // ⚠️ buffer 可能非 4/8 字節對齊
while (*wp++ == 0 && wp < buffer + 4096);  // 可能 SIGBUS
if (wp >= buffer + 4096) { /* 全零 */ }

實驗復現 (Windows Mobile / ARM)

long zero_buf[24] = {0};
long* wp = (long*)((char*)zero_buf + 3);  // 故意錯位 3 字節
while (*wp++ == 0);  // 💥 EXCEPTION_DATATYPE_MISALIGNMENT

根因：嚴格對齊架構

安全高效方案對比

方案 3 完整實現：手動對齊 + 字長掃描

bool is_zero_buffer(const void* buf, size_t len) {
    const uint8_t* p = (const uint8_t*)buf;
    const uint8_t* end = p + len;

    // 1. 逐字節處理頭部直到對齊
    while ((uintptr_t)p % sizeof(uintptr_t) && p < end) {
        if (*p++) return false;
    }

    // 2. 字長級掃描中間段
    const uintptr_t* lp = (const uintptr_t*)p;
    const uintptr_t* lend = (const uintptr_t*)(end - sizeof(uintptr_t) + 1);
    while (lp < lend) {
        if (*lp++) return false;  // 任意字節非零 → 字長非零
    }

    // 3. 逐字節處理尾部
    p = (const uint8_t*)lp;
    while (p < end) {
        if (*p++) return false;
    }
    return true;
}

進階：借鑑 dietlibc/GLIBC 零檢測魔數

若需**定位首個非零字節**，可在字長循環中引入魔數檢測：

uintptr_t word = *lp++;
if (word != 0) {
    // 含非零字節，逐字節定位
    const uint8_t* cp = (const uint8_t*)(lp - 1);
    for (size_t i = 0; i < sizeof(uintptr_t); ++i)
        if (cp[i]) return cp + i - (const uint8_t*)buf;
}

工程建議

1. 首選 `memcmp`/`memchr`**：標準庫已處理對齊、向量化、頁邊界安全，極難手寫超越。
2. 必須手寫時用 `memcpy` 讀取字長**：`uintptr_t w; memcpy(&w, p, sizeof w);` 編譯器會優化為對齊載入或安全非對齊載入。
3. 啟用編譯器屬性**：`__attribute__((aligned(1)))` 標記結構體/指針可能非對齊，讓編譯器生成安全代碼。
4. 靜態分析**：Clang-Tidy `bugprone-undefined-memory-manipulation` 可捕獲強轉非對齊指針。

總結

「快 3 倍」的前提是 x86 寬容非對齊訪問。追求極致效能不應犧牲可移植性與正確性。**`memcpy` 讀取字長 + 標準庫優化** 才是工業級解法。