RFC-0025：Bit flag

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；
    • 在 bits 上下文中，NUMERIC-LITERAL，必须是 2 的幂。

bits 声明中的每个成员都是 2 的幂。 此方案建议不要在 bits 中使用更复杂的表达式 声明本身，也不得在 bits 常量中将它们通过 OR 运算结合到一起 和表达式。 将来可能会将其添加到 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 类型进行扩展 和值，以运用所有受支持的 绑定。

缺点、替代方案和未知问题

此方案建议仅允许无符号整数类型使用位数。 我认为可以允许将其用于有符号的底层类型， 必须比所有语言绑定更需要谨慎。 我不希望我们在

更宽泛的位场模式似乎比这更复杂 提案。 我的意思是将整数类型转换为几个位的范围， 以字段的形式为每个位范围命名

& 和 ~ 表达式感觉没有必要，至少一开始是不必要的。 目标语言可以选择支持针对位的此类算术表达式 标志值，但我还没有发现需要在 FIDL 常量中直接使用它们。

先验技术和参考资料

他们犹豫是否要对会员价值采取过于复杂的做法，并避免 签名类型基于与 C 和 C++ 中的这些概念的永恒混淆， 其绑定必须支持此概念。