數組越界真可怕，莫名就闖到了別人家

　　4

　　筆者曾經在《天靈靈地靈靈，遙控為何會失靈》一文中講述過報文解析程序的一部分原理和設計，

　　“射頻位到數據位采用了曼徹斯特編碼形式，以射頻位01表示數字位1，以射頻位10表示數字位0，BCM采用上升沿觸發中斷的方式，根據相鄰兩個上升沿之間的時間間隔來賦值射頻位。BCM根據遙控報文的格式提取出“數據場”中的射頻位位流，然后進行曼徹斯特解碼，計算出數據位位流，進而提取出字節形式的數據。。。。相鄰兩個上升沿的間隔取值只可能為2T、3T、4T，T為射頻位位寬。”

　　前文所述“把數據位0或1這個‘大象’放到前面打開的‘冰箱’里”，指的就是賦值射頻位的過程，

　　如果是2T，執行StoreRfBit(0); StoreRfBit(1);

　　如果是3T，執行StoreRfBit(1); StoreRfBit(0); StoreRfBit(1); 或者StoreRfBit(0); StoreRfBit(1);

　　StoreRfBit(0);

　　如果是4T，執行StoreRfBit(1); StoreRfBit(0); StoreRfBit(0); StoreRfBit(1);

　　遙控報文的格式非常規整，能夠很容易地找到數據場的第一位，然后次序收完數據場的最后一位，本不該出現接收報文失敗的問題。既然無法通過分析代碼找出bug，那就只好祭出“調試大法”了。繼續添加測試語句：

　　if(Rf_bit_count >= RF_RAWBIT_LEN){

　　Rf_frame_times++;

　　StoreRfCompleteIdx();

　　SetRfFrameComplete();

　　}

　　灑家這次沒有吝惜RAM，開了個足以存儲好幾條報文射頻位位寬數據的輪轉型大數組，在判斷接收到一幀完整的報文語句那里存儲完整報文最后一個數據位在輪轉型大數組中的下標位置，設置斷點，運行到斷點位置后，便可以從這個數組下標往前搜索，看看之前幾個報文的射頻位位寬數據是否有什么異常。

　　聰明的讀者肯定已經搶先一步意識到了，射頻位位寬沒有出現任何異常。報文頭很規則，數據場很整齊，報文尾部也很利落。

　　總之，所有的射頻位數據安安靜靜地等待在時間的無涯荒野里，沒有早一步，也沒有晚一步，我遇上了，卻沒有輕輕地說一句：哦，原來你也在這里呵！

　　灑家揉了揉因為看數據看得有些發脹的眼睛，緩緩走到窗臺前，瞇縫起眼睛，打量了一下遠處籠罩在一片蜃氣之中的青山。每每遇到難解的問題，灑家總要到窗臺陽光的沐浴中，眺望一下遠處的山，讓腦袋放空，然后閉上眼睛，靜下心來，等著靈感不請自來。

　　中央空調沙沙的換氣聲音、同事的竊竊私語聲不時入耳，我在心里不斷回憶著有限的職業生涯里遇到的一個個bug，同時盤算著當前程序可能的缺陷。報文格式的分段解析肯定沒問題，射頻位位寬的判斷也沒問題，射頻位的賦值也沒問題，想來都沒有問題，這個bug隱藏地夠深的。

　　5

　　還得調試！行文至此，我不禁懷疑起了自己的智商，為什么基本上所有難題的解決都是靠調試解決的？沒有一次是靈光電閃，看代碼直搗黃龍，找出bug的？

　　被這個難題耗損了大半豪氣的我，老老實實地開始調試起來。為了定位bug，筆者特意修改了程序結構，之前的程序是邊接收邊解析，實時性固然好，但是接收了幾個數據便解析，不利于調試，所以改為收到兩三條報文后，再集中進行解析。

　　灑家看代碼找bug的本事沒有，設計調試方案找bug的能力還是有的。修改程序之后，調試下來，問題就慢慢浮上水面了。程序解析出報文頭部，進入數據場之后，在賦值射頻位的過程中，結果出現了Rf_bit_count從288累加到33的情形！！！

　　奇怪了，288累加一下應該是289，怎么就變成33了？莫非1+1不等于2了不成？！！此處肯定有蹊蹺，灑家打眼一瞧，馬上看出了一點端倪，289和33正好差了一個256，就好像是把向高字節的進位吃掉了一般。問題開始變得有趣了！

　　Rf_bit_count是個16位的數據，好像突然變成了8位數據，顯然，它的高位字節發生了不為人知的變化！寫過多年代碼的灑家，立馬想到了是和Rf_bit_count臨近空間的數據搞的鬼，回到定義位置一看，

　　uint8_t  Rx_buffer[RF_DATA_LEN];

　　uint8_t  Rx_rawbit[RF_RAWDATA_LEN];

　　uint16_t Rf_bit_count;

　　一切都了然了，Rf_bit_count挨著Rx_rawbit這個數組，肯定是Rx_rawbit這個數組搞的事，這個數組越了界，就會改變Rf_bit_count的數據，下面就簡單了，看看是不是這回事！

　　我飛速地在紙上算了一下，當Rf_bit_count=288時，右移三位為36，Rf_rawbyte_idx =36時，Rx_rawbit數組正好越界，由于Rf_bit_count的位置正好在Rx_rawbit之后，而且所使用的處理器是大端模式，大端方式將高位存放在低地址，小端方式將低位存放在低地址。

所以，Rf_bit_count的高字節正好挨著Rx_rawbit數組，肯定是對Rx_rawbit[36]賦值為0了，導致Rf_bit_count本來是1的高字節變成了0，于是289就變成了33，這樣一來，判斷接收到一條完整報文的語句里的if語句里的條件肯定是false了，于是，好好的一幀數據就這樣被漏掉了。

　　if(Rf_bit_count >= RF_RAWBIT_LEN){

　　SetRfFrameComplete();

　　}

　　當然，細心的讀者可能會比較奇怪，只需要接收288個射頻位，為什么Rf_bit_count還會累加到289呢？

　　這是因為，最后一個數據位可能是1也可能是0，最后統計到的射頻位寬可能是2T、3T或者4T，它們執行的Rf_bit_count是不一樣的，有時正好統計到288，那自然萬事大吉，可以接收到報文，可是有時就會超過288，如前所述，這時它的高字節就有可能會被Rx_rawbit[36]吃掉，這就接收不到報文了。

　　后記

　　筆者學過一段時間的Java，Java對數組進行了一定的安全處理，在運行期間會自動判斷數組下標是否越界，當時看的灑家羨慕得不得了。在計算機的世界里，C語言飽經滄桑，年頭太老了，這種優異的特性顯然指望不上，我等嵌入式工程師只能擦亮慧眼，始終保持警惕，要知道：數組越界真可怕，莫名就闖到了別人家。