首页 > 解决方案 > 为什么 CDROM_TOC.Length 是 UCHAR[2] 而不是 WORD?

问题描述

文档中,长度由两个无符号字节组成:

长度

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

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

标签: cwinapiioctluint16

解决方案


在深入研究文档之后:

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

这将我们带到这里:

https://ia802909.us.archive.org/35/items/mmc3r10g/mmc3r10g.pdf

当您浏览这 471 页的单词endian时,结果为零,对于单词integer只有五个结果。

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

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


推荐阅读