本頁面由 Cloud Translation API 翻譯而成。

RFC-0025：位元標記

RFC-0025：B 標記
狀態	已接受
領域	FIDL
說明	使用 Bit 旗標宣告擴充 FIDL 語言。
作者	kulakowski@google.com
提交日期 (年-月-日)	2019-01-14
審查日期 (年-月-日)	2019-01-24

編輯此 RFC

編輯 RFC 中繼資料

「只是稍微有用」

摘要

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

提振精神

在 FIDL。目前，我們建議 FIDL 的使用者將一組常數設為基礎類型這些值均各自獨立，因此建立無效值時無法繫結作業偵測到的 KPI 作業

設計

原文語言變更

這項提案會將 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]

注意：

bits-declaration 允許文法中較為寬鬆的 type-constructor，但編譯器會將此參數限制為無正負號整數類型，請參閱基本類型。
bits-or-enum-member-value 允許在文法中加入較為寬鬆的 literal，但編譯器會將此限制為：
- enum 中的 NUMERIC-LITERAL；
- 在 bits 中，NUMERIC-LITERAL 必須是兩個的次方。

bits 宣告中的每個成員都是二次方。本提案建議不允許在 bits 中使用較複雜的運算式同時允許在 bits 常數中搭配使用為求簡單起見系統日後可將這類宣告加入 bits 宣告中。

bits 宣告的範例，擷取自 fuchsia.io 程式庫：

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。但做為 bits 類型，0、3、5、6 和 7 也都是有效的類型。

繫結

每個語言繫結都會擴充，以慣用方式處理這些值。在最糟的情況下，這樣只會為每個 bits 成員產生常數，就像為基礎類型的積分常數。

bits 值的線路格式與基本積分值相同。

序列化和反序列化程式碼應確保該值是在此輸入說明文字舉例來說，若嘗試以 8 做為 OpenRights 值，驗證失敗的方式應會失敗。

信號和權利常數

我也建議在 zx 程式庫中新增信號，並處理適當的值。這包括包含所有信號值和權利的 bits 宣告；且可能為各個帳號代碼類型提供預設權利的一組常數。

執行策略

第 1 階段

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

第 2 階段

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

第 3 階段

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

人體工學

這項變更讓 FIDL 更加符合人體工學，而讀者可以看到明確分組

說明文件和範例

本提案說明上述 FIDL 文法的變更。

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

回溯相容性

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

電線格式具有回溯相容性，就如同以 uint32 或 bits Bits : uint32 傳送，與電線上的 (2 | 4) 或 6 值相同。

成效

將 FIDL 中的類型從 uint32 變更為 bits 值，檢查序列化或去序列化作業是否會產生些微負擔輸入的值有效。

這是位元遮罩和分支版本，不易察覺。

安全性

我沒有發現安全性方面的缺點。更好的型別安全或許是少不了的。

測試

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

相容性測試套件將擴充為各種大小的 bits 類型和值來練習使用所有受支援的繫結。

缺點、替代方案和未知

本提案建議只允許無正負號整數類型使用位元。我認為可以允許簽署已簽署的基礎類型，而且所有語言繫結都更謹慎我們不希望在 C/C++ 中不小心。

處理這個問題時，一般的位元模式似乎更加複雜提案。我的意思是將整數型別轉換為幾個位元的範圍以欄位形式呈現每個範圍

覺得 & 和 ~ 運算式不必要，至少從一開始就稱為「非必要」。目標語言可在位元上支援這類算術運算式標記值，但我還沒有在 FIDL 常數中直接使用這些值。

既有藝術品和參考資料

面對成員價值觀，有必要做太過複雜的工作，但為了不著想是有常識與 C 和 C++ 中這些概念的混亂了，其繫結必須支援這個概念。