Re: Reading an unaligned integer in little endian

[Jose E. Marchesi]

Hi Ege.
    
    This got stuck in my mind. Can you please check the following two
    paragraphs below? The first one is what the ios currently does. I
    wonder if it should do what's described in the second paragraph
    instead. I cannot imagine the use of the former while I can imagine
    the latter after John's example. If you also agree that my previous
    logic was wrong and should be replaced with the second paragraph
    below, I will do so.
    
    (This is purely about the bit order in little endian. Big endian
    integers are read fine in all cases.)


In poke the endianness of bytes is configurable.

However, the endianness of bits is not, and it is assumed to be big,
i.e. the most significative bit always comes first in the containing
byte.

Or that's the idea.

This is what I would expect in the example you show:

In big endian:

IOS bit offset:  52 53 54 55 56 57 58 59 60 61 62

byte number:               1            |    0
bit number:      10  9  8  7  6  5  4  3  2  1  0

In little endian:

IOS bit offset:  52 53 54 55 56 57 58 59 60 61 62

byte number:         0   |            1
bit number:       2  1  0 10  9  8  7  6  5  4  3

Note how it is always the least-significative byte that is incomplete,
in case where the number of requested bits doesn't complete a byte.
This is a simple and predictable rule for the user.

This seems to match what you describe in the second paragraph.
We really need to document this...