Bit syntax frustrations, again (LONG)

[Matthias Lang]

    mml> (* Bits-in-a-byte the wrong way around can happen, but
    mml> surely not in a file format. When you transmit SS7 traffic
    mml> over a E1/T1 PCM line, you send the LSB first. When you send
    mml> voice over the same line, you send the MSB first. [...]

 tony> This is a attempt to solve this question once and for all :-)

Except that your suggestion solves another problem, not the one I
described. 

The SS7 problem is this: if there's an octet 0x83 (1000 0011) on the
line, the receiving hardware will put it in RAM as 0xc1 (1100 0001).
This is a pain in the arse but, once you've figured out what's going
on and condemned the authors of Q.703 to hell yet again, it's dealt
with fairly easily by adding a bit-reflect mode in hardware.

The problem you're solving is one of dealing with file formats 
designed for little endian machines:

    tony> To solve this once and for all I wote for (re)introduction
    tony> of bit groups!

    tony> To given an example of how to specify the above bit pattern
    tony> in a bit group:

    tony> << <<A:3, B:2, C:1, D:4, E:6>>:2/little >>

    tony> << <<A:3, B:2, C:1, D:4, E:6>>:2/big >> == <<A:3, B:2, C:1,
    tony> D:4, E:6>>

Syntax-wise, this doesn't seem like such a huge win over

    << Temp:16/little >> = Bin,
    <<<A:3, B:2, C:1, D:4, E:6>> == <<Temp:16>>.

though it may help the compiler generate good code.

In any case, I have a simpler solution: the authors of any little
endian protocols and file formats can go roast with the Shockwave and 
Q.703 guys.

Matthias