On Fri, 2009-07-10 at 09:23 -0700, Richard Guthrie wrote: > Andrew, > > We will continue to work to resolution on the broader issue of how to > handle bit fields in the documentation. Your feedback is much > appreciated there. For this specific issue, in general, for > custom-marshaled fields you should see a bit field that follows the > RFC convention where the high bit of the first byte to hit the wire is > in column 0, and the low bit of the last byte to hit the wire is in > column 31 (so that the bits are shown from left-to-right in the order > they naturally appear over the network).
Your two statements are inconsistent, and not consistent with what the documentation does. Do you mean to say that I can expect the above in future, or that you claim the documentation does the above? If the bits were numbers, for little-endian numbers, such that bit 0, representing integer 1 appeared a the left (the little end), and that the numbers in the heading increased 0..31 left-to-right, above the value such that for it's natural natural number representation (as indicated by the stated endianness) that value == n^2, then I would be happy. > We are going back through the documentation to ensure that custom > marshaled fields have the appropriate specification for endianness. Alternately, can you please point me at the RFC that indicates both bit numbering such that (value != n^2) where n is the described bit number, and where bits are ordered in a different order to bytes. Microsoft's documentation is the only place, ever, that I have seen this insanity. Thanks, Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco Inc.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
