[cifs-protocol] erroneous references to little-endian

Hongwei Sun hongweis at microsoft.com
Mon Aug 10 20:49:03 MDT 2009


  Richard has left our team and I have taken the ownership of this request.  In the last a few weeks, We have been actively working on updating documentation for this broad issue to improve our documentation.  We will finish the update soon.   I will let you know as soon as the detail is finalized.

  We have scheduled a meeting between the Samba team and our documentation team to have more discussion on this issue in the Samba IOLab next month.

Thanks for your patience.


-----Original Message-----
From: cifs-protocol-bounces at cifs.org [mailto:cifs-protocol-bounces at cifs.org] On Behalf Of Andrew Bartlett
Sent: Monday, August 10, 2009 2:41 AM
To: Richard Guthrie
Cc: 'pfif at tridgell.net'; 'cifs-protocol at samba.org'
Subject: Re: [cifs-protocol] erroneous references to little-endian

On Sat, 2009-07-11 at 09:42 +1000, Andrew Bartlett wrote:
> 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.

I'm still unsatisfied with the situation here.  Will there ever be any progress?

Andrew Bartlett

Andrew Bartlett
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.

More information about the cifs-protocol mailing list