跨越數據類型的重重陷阱
發布時間：2010-11-15 12:03
發布者：eetech
|
數據類型是編程語言中最基本的構成元素，但卻是最易被忽略的一環，程序員愿意把幾乎100％的精力都花在算法研究、程序流控制等大環節上，卻很少在數據類型問題上反復斟酌。 細節決定成敗，一個螺絲釘的失誤可能導致一個飛行器的毀滅，一個數據類型的錯誤同樣可以讓龐大的軟件系統崩潰。 MISRA—c中關于數據類型的規則主要分為兩個方面。一是數據類型相關的編程風格；二是不同數據類型之間的轉換，后者是重點。這里介紹MISRA_C關于數據類型的部分規則，更多的規則請參考《MISRA-C：2OO4)》一書。 下文中凡是未加特殊說明的都是強制(required)規則．個別推薦(advisory)規則加了“推薦”標識。 在展開論述之前，先看兩個問題，讀者可以帶著疑問閱讀完本章內容。 問題1：執行以下程序，result_8的值是多少? ulnt8_t porI=0x5a; uint8一t resuh_8； result_8=(～port)>>4; ／*注：uint8_t表示8位無符號整型*／ 問題2：執行以下程序，d的值是多少? uintl6_t a=10； uin|16_t b=6553l； uint32_t c=0； uint32_t d； d=a+b+c； ／*注：uintl6_t表示16位無符號整型，uint32_t表示32位無符號整型*／ 1 數據類型相關的編程風格 規則6.3(推薦)：必須用typedef顯式標識出各數據 類型的長度和符號特性，避免直接使用標準數據類型。 例如，一個32位的整數系統，可定義如下： typedef char chat_t； typedef sigrled char int8_t； typedef signed short intl6_t； typedef signed int int32_t； typedef signed long int64_t； typedef unsitgned chat uint8_t； typedef unsigned short uint16_t; typedef unsigned int uint32_t; typedef unsigned 1ong uint64_t； 之所以用intl6_t和uint32_t等代替signed short和unsigned int等標準數據類型標識符，是由于不同的編譯器對標準數據類型的長度定義是不一樣的。比如說一個16位系統，很可能就把short和int都定義成16位，long定義成32位，這與上文32位系統中標準數據類型的長度就不一致。用intl6_t和uint_32等標識符來定義變量，一方面增加了程序的可讀性，使得程序員本人或其他讀者都能對程序中數據的具體信息胸有成竹；另一方面也有助于程序在不同系統之間的移植，節省開發時間，減少隱患。規則7 1：不得使用八進制常數(O除外)或八進制轉義符。 思考如下數組： code=109； code=100； code=O52 code=O71； ／*注：八進制常數須在最高位加O*／ code的實際值是42(十進制)，code的實際值是57(十進制)；但估計很多讀者會把code認成是52(十進制)，code認成是7l(十進制)。 八進制數在C程序中使用的頻率遠小于十進制數和十六進制數，為了保證程序的可讀性和安全性，程序員不允許使用八進制數以及八進制轉義符。 2 數據類型轉換 如果程序員對數據類型的轉換有很清晰的認識，并且在必要的地方做了正確的顯式強制轉換，那程序是安全的。但有時由于程序員的疏忽，或者是過于相信編譯器的“智慧”程度，導致表達式中有很多隱式轉換(即沒有顯式地強制轉換)，而這些隱式數據類型轉換很可能就構成致命的漏洞。MISRA—C中數據類型轉換規則的著眼點，即是避免有漏洞的隱式數據轉換。 在介紹MISRA—C關于數據類型轉換的部分規則之前，先介紹整型操作數的“平衡(balance)”原則。所謂整型操作數“平衡”原則，即對于隱式表達式，編譯器會按照既定規則對操作數進行位數擴充，其中int和unsiglled int在整型表達式“平衡”過程中占重要地位。 下面分析一個簡單的隱式整型表達式c=a+b(假設a的存儲位數不大于b的存儲位數)，編譯器是這樣來處理這個表達式的： 如果b是短整型(即位數少于int，比如char、short等)或者整型(int或unsigned int)，那a也是短整型或者整型，執行“+”運算之前，a和b都將被擴充為整型(int或者unsigned int)，然后相加的結果賦給c(如果c不是int或者unsigned int類型，則這個賦值操作也會包含隱式的擴充或截斷操作)。 如果b是長整型(存儲位數多于int)，則a會被擴充為與b相當的長整型，再執行“+”運算，所得結果賦給c(可能包含隱式的擴充或截斷操作)。 絕大部分的操作符用于整型運算的時候，都遵循上述“平衡”原則，比如：算術操作符、位操作符和關系運算符。 但邏輯操作符不遵循上述“平衡”原則。此外左移(>)運算符也不遵循“平衡”原則，只和移位操作符左邊的整型操作數相關。假設一個8位的短整型變量值為Oxf5(十六進制)，則右移4位所得結果是O xof(十六進制)。 明確了上述背景后，下面來關注本文一開始提出的“問題1”(代碼參見前文)。絕大部分擁有嵌人式C程序開發經驗的人都明白這段代碼的原意是將port的值取反后右移4位賦值給result_8(在用I／O口控制共陽的LED時經常這么做)，程序員期望的結果顯然是resuIt_8=0xof。然而，由于整型的“平衡”原則，在16位編譯器中，～port的值是Oxffa5；在32位編譯器中，～pott的值是Oxffffffa5。無論哪種情況，最后結果(右移4位后賦值給result_8的時候有一個截斷操作)都是resuIt_8=Oxfa，而非程序員預期的result_8=OxOf。 倘若將最后一行代碼改成result一8=((uin8_t)(～port))>>4，則result_8可取得預期的值。 針對以上情況，MISRA-c提出了相應規則。 規則10.5：如果位操作符～和移位操作符>)聯合作用于unsigned char或者unsigned short類型的操作數時，中間運算步驟的結果必須立刻顯式強制轉換為預期的短整型數據類型。 為了加深對“平衡”原則的理解，再來分析一下“問題2”。 如果用一個32位的編譯器來編譯這段程序，最終結果是d=6554l，程序員“幸運地”得到了預期的結果。如果是16位的編譯器，得到的結果卻是d=5。 由于“+”運算是左結合的，所以d=a+b+c等效于d=(a+b)+c，即先執行a+b，所得的和再與c相加．最后結果賦值給d。問題就出在a+b這個中間步驟中。由于a和b都是16位整型(注意編譯器也是16位的)，故而a+b的結果也是16位整型，則a+b的值是Ox0005(有溢出)；再擴充為32位整型Ox00000005和c相加賦值給d，d=5，這并非程序員預期的結果。 所以，在16位編譯器中，問題2的那段代碼很可能導致嚴重錯誤。當然，如果程序員用()指定了運算優先級的話，即最后一行代碼寫成d=a+(b+c)，也可以避免上述溢出錯誤，然而，這終究不是治本的辦法。只有明確每一個操作數的實際數據類型，才能保障代碼的安全性。 MISRA-C中對于表達式中存在隱式數據類型轉換的情況作了嚴格的限制。 規則10.1：以下情況下，整型表達式中不允許出現隱式數據類型轉換。 ①整型操作數不是被擴充為更多位數的同符號整數； ②表達式是復雜表達式； ③表達式不是常數表達式，且是函數的參數； ④表達式不是常數表達式，且是函數的返回表達式。。 規則10.2：以下情況下，浮點數表達式中不允許出現隱式數據類型轉換。 ①浮點型操作數不是被擴充為更多位數的同符號浮點數； ②表達式是復雜表達式； ③表達式是函數的參數； ④表達式是函數的返回表達式。 整型表達式規則和浮點數表達式規則基本類似，只是浮點數表達式規則更為苛刻一些，對浮點型的常數也作了嚴格的限定。 這兩條規則中，出現了“復雜表達式”的概念。請注意，MISRA—C中“復雜表達式”的概念和其他介紹C編程規范書籍中“復雜表達式”的概念是不一樣的。在MISRA-C中，非“復雜表達式”基本只限制在常數表達式或者函數的返回值。為了明確上述規則中關于“復雜表達式”和“返回表達式”的概念，此處舉一例子。定義一個函數uintl6_t foo(void)，函數體如下： uintl6_t foo(void){ return(a+b+c)； 函數體中最后一句return(a+b+c)中的a+b+c是返回表達式。倘若在C程序的其他地方有a=foo()這樣的語句，則用的是foo()函數的返回值。在MISRA-c中，的資源，完成了采用USB接口技術的熱敏打印機的開發，并對打印頭作了充分的保護。通過采用相應的算法實現這個賦值表達式不是“復雜表達式”。 至于表達式作為函數參數等情況，礙于篇幅的原因，此處就不再詳細展開了。 權衡一下利弊，在涉及到數據類型轉換的時候，與其花很大力氣去區分一個隱式表達式是否在MISRA—C規則的“黑名單”中，還不如用強制轉換符顯式地標識出每個操作數的實際數據類型，這是最為穩妥的方法�？偠灾�，MISRA—C關于數據類型轉換規則的中心意思，是要求程序員明確任意一個操作數的實際數據類型。 3 小 結 作為一名優秀程序員，第一步就是以嚴謹的態度對待程序中的每一個數據，明白任何一個數據操作的關鍵，從而能寫出最清晰易懂而又安全的代碼。MISRA—C關于數據類型的規則可保障程序員在邁出這一步的時候不會摔倒。 |
網友評論