RFC-0025：位元標記

RFC-0025：位元標記
狀態已接受
區域
  • FIDL
說明

使用位元旗標宣告擴充 FIDL 語言。
作者
提交日期 (年/月)2019-01-14
審查日期 (年/月)2019-01-24

編輯此 RFC

編輯 RFC 中繼資料

「只是小小的一點」

摘要

使用位元旗標宣告擴充 FIDL 語言。

提振精神

有多種用途適合用來描述 FIDL 中整數的一組標記。目前，我們建議 FIDL 使用者為相同基礎類型的一組常數。由於這些項目全都各自獨立，因此繫結無法在執行階段偵測到無效值的建立作業。

設計

原文語言變更

此提案會將 bits 關鍵字新增至 FIDL。

bits 引進了頂層宣告，類似於 enum。 文法的正式成分如下：

bits-declaration = ( attribute-list ) , "bits" , IDENTIFIER , ( ":" , type-constructor ) ,
                   "{" , ( bits-or-enum-member , ";" )+ , "}" ; [NOTE 1]

bits-or-enum-member = ( attribute-list ) , IDENTIFIER , ( "=" , bits-or-enum-member-value ) ;

bits-or-enum-member-value = IDENTIFIER | literal ; [NOTE 2]

注意：

  1. bits-declaration 文法可允許更多元的 type-constructor，但編譯器會將此限制為無正負號整數類型，詳情請參閱「基元」。

  2. bits-or-enum-member-value 允許文法結構中更合意的 literal，但編譯器會將以下動作限制為：

    • enum 中的 NUMERIC-LITERAL；
    • NUMERIC-LITERAL，在 bits 的情況中必須是二的冪次方。

bits 宣告中的每個成員都是二的次方。為求簡單起見，本提案建議不要在 bits 宣告本身中允許使用更複雜的運算式，也不允許在 bits 常數運算式中將運算式進行 OR 結合。日後可以加到 bits 宣告中。

從 fuchsia.io 程式庫目前提供的常數取得的 bits 宣告範例：

bits OpenRights : uint32 {
    READABLE = 0x00000001;
    WRITABLE = 0x00000002;
    ADMIN = 0x00000004;
};

此外，這個提案加入了二進位常值語法，如下所示：

bits OpenRights : uint32 {
    READABLE = 0b0001;
    WRITABLE = 0b0010;
    ADMIN = 0b0100;
};

語義

溢位基礎整數類型會產生編譯錯誤。

每個 bits 成員值皆不得重複。

如果使用不是 bits 宣告成員的位元集將 bits 值序列化或反序列化，就會造成驗證錯誤。

bits 的語意與 enum 不同。enum 值必須是 FIDL 中宣告的其中一個值，而 bits 不得。舉例來說，如果 OpenRights 是 enum，則只能傳送的有效值是 1、2 和 4。不過，0、3、5、6 和 7 都屬於 bits 類型。

繫結

每個語言繫結都會延伸，以慣用方式處理這些值。最糟的是，這樣只會為每個 bits 成員產生一個常數，就像是基礎類型的常數常數一樣。

bits 值的傳輸格式與基礎積分值相同。

將程式碼序列化和去序列化，應確保該值是所述位元的子集。舉例來說，嘗試使用 8 做為 OpenRights 值應該會導致驗證失敗。

信號和權利常數

此外，我也建議在 zx 程式庫中加入信號並處理正確的值。這包括所有信號值和權利的 bits 宣告，可能包括一組常數，以及每個帳號代碼類型的預設權限。

導入策略

第 1 階段

將所有來源變更新增至 FIDL 編譯器，包括剖析器測試。

第 2 階段

新增對所有語言繫結和相容性測試套件的支援。

第 3 階段

將現有的堆積常數遷移至 bits。

人體工學

這項變更藉由讓使用者明確表達意圖，讓 FIDL 更符合人體工學。

說明文件與範例

本提案說明上述 FIDL 文法異動。

我會調整 FIDL 教學課程，加入這個模式的範例。

回溯相容性

這是與 FIDL 來源回溯相容的變更。

由於 (2 | 4) 或 6 的值與以 uint32 或 bits Bits : uint32 傳送時，線路格式相同，因此線路格式具有回溯相容性。

效能

將 FIDL 中的類型從 uint32 變更為 bits 值時，在檢查序列化或去序列化值是否有效時，繫結會產生一些小負擔。

此為位元遮罩和分支，因此不容易察覺。

安全性

我沒有發現安全性的缺點。 安全性較高的類型安全性可能有些許缺點。

測試

fidlc 個主機單元測試將執行 FIDL 剖析器。

相容性測試套件將擴充為各種大小和值的 bits 類型，以行使所有支援繫結的傳送和接收路徑。

缺點、替代方案和未知

本提案建議僅允許無正負號整數類型的位元。我認為可能允許已簽署的基礎類型，但比所有語言繫結的需要更加謹慎。我不希望我們不小心在 C/C++ 中移動位元太遠，尤其是

對這個提案來說，較通用的位元欄位模式似乎比實際值更複雜。這表示，將整數型別寫成數個位元的範圍，並將每個範圍的名稱指定為欄位。

& 和 ~ 運算式似乎沒有必要 (至少先出現)。目標語言可選擇針對位元旗標值支援這類算術運算式，但我尚未在 FIDL 常數中直接支援這類運算式。

先前的圖片和參考資料

光是用成員值處理過於複雜，並避免使用已簽署類型，我們的顧慮是基於 C 和 C++ 中的這些概念，讓繫結支援這個概念。