4

In the documentation the length is made of two unsigned bytes:

Length

Indicates the length, in bytes, of the table of contents data. This length value does not include the length of the Length member itself.

When you form a WORD in Little Endian, indeed it is the correct value, but why did they choose to not use a WORD directly ?

aybe
  • 15,516
  • 9
  • 57
  • 105
  • 1
    How weird -- either it should be a proper `WORD` (indicating, uh, Microsoft's native endianness?) or it should *at least* mention which of the two bytes are the low and high end. (Which would be to indicate this structure does not care about native endianness.) – Jongware Feb 02 '20 at 23:04
  • 3
    It seems like all the related structures use `UCHAR` arrays rather than larger datatypes. No doubt somewhere the endianness is documented (maybe it's set by the ISO standard or something). – Jonathan Potter Feb 02 '20 at 23:18
  • I think I've found the answer and posted one, just a guess but actually the notion of endianness might be a little too high-level at this level... – aybe Feb 03 '20 at 00:34

1 Answers1

2

After digging deep through the docs:

For information about the permissible values for this member, see specification T10/1363-D, by National Committee for Information Technology Standards (NCITS).

This leads us to here:

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

When you look through these 471 pages for the word endian, there are zero results, for the word integer there are only five results.

But in 5.23.2 TOC/PMA/ATIP Response Data Format 0000b, we can infer that since in that table next to Bit 0 there is (LSB), it is indeed a 16-bit integer in Little Endian Big Endian (thanks Hans).

In conclusion, they just made the struct look as it's laid out in these specs.

Community
  • 1
  • 1
aybe
  • 15,516
  • 9
  • 57
  • 105