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

魚鷹曾經因為一個很基礎的知識，差點毀了整個項目，這不是危言聳聽。

因為這個代碼用于整個系統自檢，一旦運行出錯，整個系統就廢了。

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

uint16_trun_cnt, run_cnt_next;


void function1()
{
dosomething;
run_cnt++; // 自加，表示該函數已執行
}
int main()
{
while(1)
{
function1();
if(run_cnt!=run_cnt_next+1)//判斷兩個變量是否匹配
{
doerrorsome thing
}
run_cnt_next++;//這個位置也自加，表示這里已執行
}
}

if(run_cnt != run_cnt_next + 1) // 判斷兩個變量是否匹配
{
      do error some thing
}

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



這樣就會導致在溢出時，兩者是不相等的。 比如上一次run_cnt 為0xFFFF 時（受位數限制，最大只能是這個），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
}