| RFC-0059：矢量、字符串和数组计数字段中的预留位 | |
|---|---|
| 状态 | 已接受 |
| 区域 |
|
| 说明 | 此 FTP 提出了一些变更。向量、字符串和数组的计数上限为 32 位（最大值为 232-1）。向量和字符串计数字段的高 8 位预留给绑定使用，用于内存中用途。它们必须在有线连接上填充零。向量/字符串计数字段的后续 24 位已预留，但未使用，必须在有线传输时填充零。它们无法用于绑定，并且可能会在未来的 FTP 中重新分配。 |
| 作者 | |
| 提交日期（年-月-日） | 2020-03-16 |
| 审核日期（年-月-日） | 2020-03-19 |
摘要
FIDL 向量（和字符串）使用 64 位计数字段来表示编码字节数。此 FTP 提出了一些更改：
向量、字符串和数组的计数上限为 32 位（最大值为 232-1）。
向量/字符串计数字段的高 8 位预留给绑定用于内存中。它们必须在有线连接时填充为零。
矢量/字符串计数字段的后续 24 位已预留，但未使用，并且必须在有线传输时填充零。它们无法用于绑定，并且可能会在未来的 FTP 中重新分配。
现有 64 位计数字段的细分可视化图表。
这样一来，向量、字符串和数组编码的最大大小将从 18.45 EB 减少到 4.29 GB。
设计初衷
LLCPP 绑定支持对象的就地编码。作为 LLCPP Builder 工作的一部分，绑定现在会跟踪内存所有权，以简化用户创建对象的过程。具体而言，对于矢量，计数字段的最高有效位 (MSB) 用于存储所有权信息（请参阅 vector_view.h）。 此位在序列化期间归零，不会影响 FIDL 有线格式，但会阻止 LLCPP 绑定将 MSB 用于计数值。
此举旨在正式预留向量计数字段的 MSB 以供绑定使用，并将预留范围扩展到高 8 位。
另外，绑定之间的最大数量存在一些不一致之处。C++ 语言绑定和编译器的各个部分都假定最大大小为 32 位，但此大小从未正式确定，其他绑定也不遵循此大小。此 FTP 将向量/字符串/数组计数的最大大小正式确定为 32 位。
设计
64 位向量（和字符串）计数字段的高 8 位预留给绑定在内存中使用。通过线路发送时，高 8 位必须为零。
此外，接下来的最高 24 位（第 32-55 位）是保留位，绑定不得使用。它们在传输时也必须为零。
ABI 保持不变。
实施策略
每个绑定中的编码和解码逻辑都将更新，以验证数量是否最多为 2^32-1。这包括验证高位是否为零。如果在解码期间违反此限制，相应渠道将被关闭。
工效学设计
不适用
文档和示例
线格式文档将更新，以显示预留位。
向后兼容性
每个消息的通道大小上限为 65536 字节（16 位），因此 FIDL 编码到通道消息中的系统部分不会有任何兼容性问题。此外，部分代码已假设向量/字符串/数组的最大数量为 232-1。
性能
对性能的影响微乎其微。唯一的实现更改是添加了验证检查。
安全
这不应带来任何安全风险。通过网络传输的 count 字段将具有相同的值，并且现在有额外的验证检查。
测试
每个绑定实现都负责测试其功能实现，包括测试验证检查。
缺点
在此 FTP 之后，绑定能够将计数字段的高 8 位用于任何目的。因此，很难或无法将这些位重新用于新用途，这需要详尽地验证每个绑定是否未使用这些位，并可能需要将它们迁移到不使用这些位。
替代方案
与其将矢量所有权信息存储在计数字段中，不如将其存储在矢量的指针字段中。
有两种可能的方法：
假设对齐方式为 >= 2 字节，并将所有权布尔值存储在最低有效位中。这种方法的问题在于，2 字节对齐的假设很难强制执行，而且通常并不成立。在代码库中，有些地方会从缓冲区中的任意偏移量读取字节。
使用地址空间的属性来分配未使用的位，以保存内存所有权信息。但这样做的缺点是，无法保证内存空间中的位未被使用。即使现在情况确实如此，地址清理器等工具也倾向于将信息存储在指针中的可用位中，这些工具与 LLCPP 之间可能会发生冲突。
此外，还有人讨论了要为绑定预留的位数以及向量数量应有多大。支持使用较大向量数量的一个理由是，很难预测未来的需求，并且其他系统曾因任意大小限制而遇到问题。不过，写入大于 4.29 GB 的 FIDL 对象的实际使用场景很少。如果假设当前 CPU 上每个元素的周期为 1，那么对包含如此多元素的的对象进行编码或解码将需要超过 1 秒的时间。可以更高效地编码的大型原始数组通常应通过 VMO 等替代机制发送，而不是通过 FIDL 发送。不过，为绑定预留过多的位可能会限制未来的使用场景。作为一种折衷方案，8 位用于绑定，24 位未使用，32 位用于计数。这样一来，日后便可根据需要进行更改。
在先技术和参考资料
不适用