为什么 CDROM_TOC.Length 是 UCHAR[2] 而不是 WORD？答案

【问题标题】：Why is CDROM_TOC.Length an UCHAR[2] instead of WORD?为什么 CDROM_TOC.Length 是 UCHAR[2] 而不是 WORD？
【发布时间】：2020-05-18 17:55:48
【问题描述】：

在documentation 中，长度由两个无符号字节组成：

长度

表示目录数据的长度，以字节为单位。此长度值不包括 Length 成员本身的长度。

当你在Little Endian中形成WORD时，确实是正确的值，但为什么他们选择不直接使用WORD？

【问题讨论】：

多么奇怪——要么它应该是正确的WORD（表示，呃，微软的原生字节序？）要么它应该至少提到两个字节中的哪一个是低端和高端。（这将表明此结构不关心本地字节序。）
似乎所有相关结构都使用UCHAR 数组而不是更大的数据类型。毫无疑问，在某处记录了字节顺序（也许它是由 ISO 标准或其他东西设置的）。
我想我已经找到了答案并发布了一个，只是一个猜测，但实际上字节序的概念在这个级别上可能有点太高级了......

【解决方案1】：

深入挖掘the docs之后：

有关此成员的允许值的信息，请参阅国家信息技术标准委员会 (NCITS) 的规范 T10/1363-D。

这将我们带到这里：

当您在这 471 页中查找单词 endian 时，结果为零，对于单词 integer 只有五个结果。

但是在 5.23.2 TOC/PMA/ATIP 响应数据格式 0000b 中，我们可以推断，由于在 Bit 0 旁边的那个表中存在 (LSB)，它确实是 ~~Little Endian~~ Big Endian 中的 16 位整数（感谢 Hans）。

总之，他们只是让结构看起来与这些规范中的布局相同。

【讨论】：