RFC-0048：明確聯集普通

RFC-0048：明確聯集序
狀態已接受
領域
  • FIDL
說明

為了更妥善地比對可延伸聯集 (或聯集) 對 ABI 的影響，我們提議進行變更，讓彈性聯集與表格的語法更近，並修正奇數 [2] 與非嚴格的 ABI 限制，解決工會或工會成員重新命名的問題。
作者
提交日期 (年-月-日)2019-08-25
審查日期 (年-月-日)2019-09-26

編輯此 RFC

編輯 RFC 中繼資料

摘要

為了更妥善地對齊可延伸聯集 (或聯集) 對 ABI 的影響，我們 建議：

  1. 變更變化版本成員的語法，要求使用明確的序數 (序數) (類似於資料表序數的必要方式)。
  2. 使用這個明確序數，而非先前導入的雜湊值 序數
  3. 最後，我們變更線路格式，將聯集序數為 64 位元 (而非 32 位元)。

這些變更使彈性聯集語法更接近資料表。 目前更正了奇數異常1和實施嚴格的 ABI 限制 重新命名工會或工會成員。

動力與設計

除了聯集外，在型別方面的 ABI 作業時 (列舉、位元、 您可以重新命名結構體和資料表，或是將成員重新命名，但沒有任何項目 二進位檔的相容性聯合體不同，因為我們選擇使用 雜湊式技術以指派變體序 (請參閱 RFC-0061：可延伸) 聯集)。

我們已經認可這個缺點，並且建議可以解決這些問題：請參閱 要實作的意圖：聯集序數變更，表示 變更雜湊配置，只納入成員名稱。

這項提案會更進一步 如此一來，就能避免名稱與 ABI 相容性之間有任何關聯。我們會考量 請盡量減少在聯集宣告中寫出序數 資料表中的明確序數並沒有問題 。

此外，為了與資料表更一致，我們對一般樣本的要求 由 1 依序指派，並允許關鍵字 reserved 用於 我們會明確略過聯集變體

僅針對通訊協定進行雜湊處理

與型別不同，通訊協定會使用雜湊式方法來指派序數。這是 以兩個主要用途為動機：

這些用途不會轉譯為類型。

本提案的作用是進行雜湊處理僅適用於通訊協定。另有 只有一個雜湊配置，也就是 RFC-0029 中所述的通訊協定。

64 位元序數為標準

目前，聯集內嵌內容中有 4 個位元組的邊框間距：

  • 序數 (uint32)
  • 邊框間距 (uint32)
  • 信封 (16 個位元組)

相反地，我們希望以 格式明確地呼叫所有位元組 因此將序數變更為 64b一般來說，我們偏好無邊框間距 因為這類結構較有效率 (例如不需要顯露口碑) 或額外的編碼表)。

請參閱「導入策略」一節，瞭解如何 34 位元一般體溫經過柔性轉換。

JSON 傳輸格式

我們過去曾討論過，當我們建立 JSON 線格式、重新命名時 不同類型的型別和成員都會對該格式產生 ABI 的影響。

按「線路」區分 ABI 故障時，會很有幫助。我們可以 來自不同資源的不同資源需要 ABI 的罕見訊息 能夠支援所有可能的電匯格式 但日後可能會變得越來越高有些廣告客戶則應該盡可能使用更有彈性的規則。

展望未來：稀疏資料表

現在大家都討論了支援的稀疏資料表，也就是 除了 結構和 資料表。若決定採用第三種方式 遵循此提案，而目前的表格語法：

sparse_table Example {
    1: T1 field1;
    2: reserved; // deprecated
    3: T3 field3;
};

執行策略

如要啟用柔和轉場效果，我們必須區分傳統 (32 位元) 雜湊) 序數語法和提議 (64 位元明確) 的序數語法。這個 做法如下：

  1. 在 fidlc 中新增檢查，以確保 32 位元雜湊序數的值 絕不會小於 N。舉例來說，如果 N 是 512，則雜湊序數的十六進位值 不得小於 0x200。
    • 符合下列敘述的雜湊序數0x200 會導致編譯錯誤，而 欄位名稱必須使用 [Selector=] 屬性手動重新命名。我們會 請先在適當欄位中加入 [Selector]，再到達這項變更。 fidlc。
    • 由於現有雜湊配置的隨機性，我們預期 因此幾乎不需要發生 無從得知
    • 新增這項檢查，可有效分配 [0..N] 序數空間給 來確保它不會與雜湊常態衝突。
  2. 語言繫結解讀序數值時：
    • 如果序數介於 [0, N) 之間，序數為 64 位元。
    • 如果序數介於 [N, UINT32_MAX] 之間，序數為 32 位元並經過雜湊處理
    • 如果序數介於 [UINT32_MAX, UINT64_MAX) 之間，繫結「必須」叫用 並用語音關閉管道

人體工學

能以極最少的語法成本，簡化 ABI 人體工學。

說明文件和範例

須符合以下條件：

回溯相容性

沒有明確序數語法定義的聯集會繼續使用 現有 32 位元雜湊一般配置。現有的聯集 仍與 API 和 ABI 相容。

使用明確序數語法定義的聯集將使用 64 位元序數配置 用於定義此 RFC 中繼資料請參閱導入 策略部分，說明如何同時支援 32 位元版本 以及 64 位元序數配置

成效

大幅改善：這項配置比雜湊常式更有效率，因為它能更有效地對 Switch() 陳述式使用 Codegen。

安全性

沒有影響。

測試

與平常一樣。

缺點、替代方案和未知

替代方法：僅對成員名稱進行序數雜湊

請參閱「要實作的意圖：聯集序數變更」。

經過進一步思考後，我們並未將上述內容納入考量 語法優勢 (來源中無序數) 無法補償：

  • 導致使用者難以瞭解 ABI 影響的兩種雜湊配置；
  • 會讓聯集與同層列舉、位元、結構體和資料表不同。 變更宣告或成員名稱

既有藝術品和參考資料

沒有任何特別相關之處。

Footnote1

「聯合國」在本文件中是指可延伸聯集，而非「靜態」 停止服務終止的工會

Footnote3

寄件者：apang@google.com
收件者：篩選使用者名單
日期：2019 年 5 月 23 日

FIDLers，您好！昨天撰寫測試時，FIDL 團隊發現令人意外 現行 X Union 規格會發生的行為，以及簡單來說，如有應用程式宣告這個元素：

xunion MyXUnion {
    int32 i;  // ordinal might be 0x11111111
}
````

and renames the name of the xunion (not the field), the ordinal of the field
changes:

```fidl
// rename from MyXUnion to MyXUnion2
xunion MyXUnion2 {
    int32 i;  // ordinal now changes to 0x22222222 since the xunion was renamed. d'oh!
}

這可能是非預期的行為：不應變更 xunion 的名稱 變更 ABI。

改善這個做法代表兩件事：

  1. 我們要修改 xunion RFC (RFC-0061)，讓序數衍生 移除，移除 Xunion 名稱，從 序數雜湊計算。
  2. 我們需要變更程式碼，但遺憾的是，xunion ABI 會變更 且可能導致版本品質不佳幸好，我們可以進行柔和轉換作業 進行了 Jeremy Manson 為實際應用 如何雜湊方法：讓用戶端會同時檢查直到 變更整組變更

(我們有一堂課學到：未來我們會仔細看看課程內容 的序數，以及這些變更是否需要變更 ABI)。

我們認為這是一個低風險的計畫，因為這有可能 進行柔和轉換，而 Jeremy 也成功完成方法序道了請 都歡迎留言，否則，我們很快就會開始處理相關工作。

  1. 眾所周知，名稱不會影響郵件的二進位傳輸格式 (即位元、enum、struct、表格)，但聯集除外。因此 能脫穎而出 ↩