什么，這個 C 語言大坑你沒見過？

開發(fā)過程中，你是否會發(fā)出“基礎不牢，地動山搖”的感慨，我相信，只要有經驗的工程師，應該都有過。

魚鷹曾經因為一個很基礎的知識，差點毀了整個項目，這不是危言聳聽。因為這個代碼用于整個系統(tǒng)自檢，一旦運行出錯，整個系統(tǒng)就廢了。

為了不讓別人篡改魚鷹的代碼，魚鷹設計了多套機制，其中一個就是定時檢查關鍵代碼是否已執(zhí)行，如果有一次沒有執(zhí)行，那么系統(tǒng)進入異常狀態(tài)，這個功能類似窗口看門狗。

• 
  

• uint16_t run_cnt, run_cnt_next;

• 
  

• void function1()

• {

•   do something ;

•   run_cnt++; // 自加，表示該函數(shù)已執(zhí)行

• }

• int main()

• {

•   while(1)

•   {

•     function1();

•     if(run_cnt != run_cnt_next + 1) // 判斷兩個變量是否匹配

•     {

•       do error some thing

•     }

•     run_cnt_next++; // 這個位置也自加，表示這里已執(zhí)行

•   }

• }

類似流程如上，當時魚鷹為了減少變量空間，將計數(shù)器設計成了 uint16_t 類型，導致埋下了隱患。

這個流程乍一看沒有問題，因為 run_cnt 比 run_cnt_next 先加，那么 run_cnt_next + 1 應該等于 run_cnt，如果不相等，作錯誤處理。

甚至短時間內運行不會有任何問題，除非 16 位溢出……

所以一個量產項目，任何一點改動，都可能需要長時間的穩(wěn)定測試，只有這樣才能確保系統(tǒng)穩(wěn)定性，不能認為自己能力強，寫的代碼不用測試就直接合并了。

原先魚鷹以為，這兩個變量都是 16 位，那么 + 1 的結果應該也是16 位，最后比較時，也是 16 位比較，這樣即使最終 16 位自加溢出了，結果也會是正確的。

• 
  

• if(run_cnt != run_cnt_next + 1) // 判斷兩個變量是否匹配

• {

•       do error some thing

• }

但你以為，終究是你以為。

實際上，因為你和  1 自加了，最終比較是按照 32 位進行比較，而 run_cnt 受到變量位數(shù)限制，始終是 16 位的結果（但擴展成 32 位比較，即高 16 位全是 0）

這樣就會導致在溢出時，兩者是不相等的。

比如上一次 run_cnt 為 0xFFFF 時（受位數(shù)限制，最大只能是這個），run_cnt_next 為 0xFFFE，此次結果比較即使按 32 位比較，也是沒有問題的，都是 0xFFFF。

但下一次運行時，run_cnt 自加，溢出變成 0，而 run_cnt_next 是 0xFFFF，再和 1 相加，因為比較會使用 32 位比較，所以此時結果是 0x10000，最終導致兩者不相等（0 != 0x10000）。

那么為什么會導致上面的問題呢？這里涉及到兩個 C 語言基礎知識點，估計大家以前都了解過，但估計沒有當回事。

1、常量默認為 int 型（但不一定是 32 bit ，和內核和編譯器有關，上面的 +1 就是 int 型）

2、整型提升（詳細可網上查找）

因為兩邊的結果類型不一致（+ 1 導致右邊結果成了 int 類型），所以最終按 int 型處理。最終導致溢出時，結果判斷失敗。

我們可以通過匯編看出一些端倪：

我們可以看到 r0 + 1 之后，直接和 r1 比較，也就是說，結果可能超過 0xFFFF，導致出錯。

那么，怎么樣才可以保證結果為 16 位呢？

我們可以這樣處理：

if((uint16_t)run_cnt != (uint16_t)(run_cnt_next + 1)) // 強制轉化為 16 位比較

{

      do error some thing

}

我們可通過匯編發(fā)現(xiàn)，多了一條 UXTH 指令，用于把 16 位結果擴展成 32 位(從這里我們也可以得出結論，結果比較總是 32 bit 比較)。

到此，分析結束，可以看到，為了解釋這么一條簡單的 C 語言語句，還是挺困難的事情。

如果對你有幫助，歡迎轉發(fā)分享支持魚鷹，這樣魚鷹也更有動力記錄原創(chuàng)筆記。