在C語言編程過程中，由于計算需要，會使用各種各樣的變量，用于給需要訪問的地址取個名稱，方便編程中使用，代碼維護者也容易理解。

這里先給大家分享一個案例，讓大家意識到變量賦初始值的重要性。

某用戶在基于瑞薩的MCU：RA6T2做開發(fā)時，發(fā)現(xiàn)一個問題，MCU發(fā)出的CAN數(shù)據(jù)幀總是莫名其妙的出錯，比如應用中明明只使用了CAN的擴展幀，但是使用捕捉工具總是能捕捉到遠程幀，出現(xiàn)遠程幀的情況毫無規(guī)律可言，有時添加一個定時器中斷，該現(xiàn)象就不會出現(xiàn)了，有時修改了代碼里某處跟CAN沒有任何關(guān)系的代碼，該問題又會出現(xiàn)，過了兩周時間調(diào)試無果。在介入Debug時發(fā)現(xiàn)，他使用的是CAN擴展幀，擴展幀使用29位ID標識符，而且對ID區(qū)數(shù)據(jù)定義了一個如下結(jié)構(gòu)體：

他在需要發(fā)送CAN幀時，申請一個如上結(jié)構(gòu)體的臨時變量can_id，在把can_id.id賦值后，再把該變量的地址傳遞給CAN的發(fā)送函數(shù)，在發(fā)送函數(shù)里使用如下語句把id的數(shù)據(jù)寫入CAN的發(fā)送消息緩沖寄存器：

如下圖，其中第30位的0表示數(shù)據(jù)幀，并不是遠程幀，31位的1表示擴展幀。

用戶是把can_id的所有數(shù)據(jù)賦值給了CFDTMID0寄存器，假如can_id.dummy中第二個位是1，會有什么后果呢？CFDTMID0.TMRTR=1，即CAN會發(fā)送遠程幀。

用戶又問：我沒有給dummy賦值啊，為什么dummy的第二個位會變成1呢？這就是問題所在了，就是因為他沒有給can_id.dummy賦值，所以can_id.dummy有可能為任意的值。下面詳細分析一下，為什么這個局部變量的值會隨意變化。

大家知道，變量根據(jù)存儲類型和用途，一般可以分成：全局變量和局部變量。全局變量，就是指分配了固定地址的變量，全局變量可以在整個代碼范圍內(nèi)使用。我們在申請全局變量時，有時對它賦一個初始值，也時也不會賦初始值，在代碼上可能看不出有什么區(qū)別，但是編譯器在編譯程序時，是區(qū)別對待他們的。對于有初始化的變量，編譯器還需要在Code Flash里（代碼存儲區(qū)）分配一段空間，把變量的初始值全部存儲在該區(qū)域里，并且在MCU的啟動代碼里插入一段程序，把這些Code Flash區(qū)的初始值拷貝到變量對應的RAM地址中。假如上面的can_id是全局變量，并且申明變量的同時并按下圖賦初始值：

這時can_id.dummy=0，如果代碼中用戶沒有再賦值，它的值也不會變化，這樣就不會發(fā)生用戶的那個遠程幀的問題了。對于沒有賦初始值的全局變量，編譯器只是分配RAM的地址，并不會修改RAM地址里的數(shù)據(jù)，那么這個變量的值就會依賴于MCU啟動時RAM里的值了。為了避免未賦值的全局變量出現(xiàn)上述的問題，我們一般會在MCU啟動代碼里插入未賦初始值全局變量的清零操作，相當于做了一個未賦初始值的全局變量的初始化賦值操作。

像上面的案例，can_id申請的是局部變量，這又是什么情況呢？

因為MCU的RAM資源有限，為了最大限度的利用RAM，MCU會提前分配一塊RAM區(qū)域，叫堆棧區(qū)，這塊區(qū)域大家共用，對于只需要在某個函數(shù)內(nèi)使用的變量，引入了局部變量概念。在開始執(zhí)行該函數(shù)時，才從堆棧里分配地址給局部變量使用，函數(shù)執(zhí)行結(jié)束后，該變量占用的RAM區(qū)域被堆?；厥眨斚麓卧僬{(diào)用該函數(shù)，再重新分配RAM。因此對于局部變量，每次申請到的地址是不同的，該地址很可能是其它函數(shù)使用過并改寫數(shù)據(jù)了的，因此每次函數(shù)調(diào)用時can_id.dummy的數(shù)據(jù)是不確定的。因為堆棧區(qū)里的數(shù)據(jù)是被反復利用的，即使MCU的初始化代碼對堆棧區(qū)域做清零處理，也是沒有意義的。

由此看來，局部變量在申請的時候賦一個初始值，是非常有必要的。雖然有時候賦初始值沒有用，但是出現(xiàn)問題時常常是致命的，而且也是非常難以定位的，你可能覺得我的代碼里后面肯定會賦值的，但是后面維護該項目的其他工程師并不一定意識到這一點。像類似上面的案例，我在其他用戶當中也是經(jīng)常見到的。因此軟件工程師在編程的時候，一定要養(yǎng)成局部變量賦初始值的習慣。

來源：瑞薩MCU小百科
免責聲明：本文為轉(zhuǎn)載文章，轉(zhuǎn)載此文目的在于傳遞更多信息，版權(quán)歸原作者所有。本文所用視頻、圖片、文字如涉及作品版權(quán)問題，請聯(lián)系小編進行處理

審核編輯 黃宇