-
類型安全
鎖定
描述類型安全系統的最簡單的方法就是描述它的對立面。有的語言(尤其是C和C++)允許做一些非常“不正當”的事情。但在合適的時候,其功能可能會很強大。但是,世界上沒有免費的午餐。所謂“合適的時候”實際很少能夠遇到。如使用不當,反而極有可能“搬起石頭砸自己的腳”。濫用類型系統就屬於這種情況。
類型安全特徵
類型安全的代碼具備定義良好的數據類型。
在即時編譯(JIT)期間,可選的驗證過程檢查要實時編譯為本機代碼的方法的元數據和Microsoft中間語言(MSIL),以驗證它們是否為類型安全,如果代碼具有忽略驗證的權限,則將跳過此過程。有關驗證更多信息。
儘管類型安全驗證對於運行託管代碼不是強制的,但類型安全在程序集隔離和安全性強制中起着至關重要的作用。如果代碼是類型安全的,則公共語言運行庫可以將程序集彼此間完全隔離。這種隔離有助於確保程序集之間不會產生負面影響,且提高應用程序的可靠性。即使類型安全組件的信任級別不同,它們也可以在同一過程中安全地執行。如果代碼不是類型安全的,則會出現不需要的副作用。例如,運行庫無法阻止非託管代碼調用到本機(非託管)代碼中和執行惡意操作。當代碼是類型安全時,運行庫的安全性強制機制確保代碼不會訪問本機代碼,除非它有訪問本機代碼的權限。所有非類型安全的代碼都必須通過傳遞的枚舉成員SkipVerification授予SecurityPermission後才能運行。類型安全的代碼是代碼訪問中非常明確,允許的數據類型的方法。微軟已經提供了。NET框架稱為PEVerify工具。PEVerify可以被用來確保CLR將只執行代碼是可驗證的類型安全的。
類型安全類型安全性
學術研究用途的編程語言,常會提出類型安全方面的需求。另一方面,許多語言以人工方式所產生的類型安全,證實經常需要上千次的檢查。不過,某些語言,如標準ML,其嚴格定義了語義,且Java也已提供類型安全。其它語言如Haskell也被認為是類型安全。暫且不理會語言定義的性質,在執行時期發生的某些錯誤,應歸於實作時的缺陷,或是用了其它語言撰寫的程式庫;這種錯誤可能使給定的實作,在某些情況下的類型不再安全。
類型安全語言的內存管理
要實現完善的類型安全語言,它至少需要垃圾回收或增加內存配置和解配置的限制(本節主要針對前者)。更明確地説,不允許懸置指標橫跨不同結構類型的存在。這有一技術上的原因:假定類型語言(如Pascal要求分配的內存必須顯式釋放)。如果存在一個仍舊指向之前的內存位址的懸置指標,新的數據結構可能會分配到同一空間。例如,如果初始化一個指向整數區域數據結構的指標,但新物件的指標區域卻分配在整數的地方,然後指標區域可藉由改變整數區域的值簡單改變成任可東西(經由間接引用懸置指標)。因為當指標改變時,尚未指定將會發生什麼,所以這個語言就不是類型安全的。大部分類型安全的語言滿足使用垃圾回收實現內存的管理。
類型安全與強類型
在各種強類型的定義中,其往往成為類型安全的同義詞;然而,類型安全與動態類型並不互相排斥。也可將動態類型視為非常寬鬆的靜態類型語言,而且所有語法正確的程式皆具備良好類型;只要它的動態語義學能夠保證絕不會有程式“搞錯”,它就可以滿足上述定義,且可稱為類型安全。
- 參考資料
-
- 1. Type conversions and type safety | Microsoft Docs .Microsoft.2021-08-04[引用日期2022-08-17]
- 詞條統計
-
- 瀏覽次數:次
- 編輯次數:24次歷史版本
- 最近更新: 雪落成殇551