Should I worry about bit order?

Question

I have reached a point in the design of a library where I am horrified by endianness.
I can easily deal with the order of bytes, but the order of bits introduces a huge level of complexity in my code.

What I am doing is converting a uint to bytes, in network byte order (big endian).
However, I use the most significant crumb (2 bits, from first [most significant] byte) for something else, storing another number.

Normally, I use these lines for writing and reading the crumb:

bytes[0] |= 0xC0 // Writing 11 to the most significant crumb. It could be 10 or 01 too. Before the disjunction, I know those two bits are 0.  
(bytes[0] & 0xC0) >> 6 // Getting the most significant crumb and shifting it to the right, in the least significant place.

To me, all these seem to assume that the most significant bit comes first.
If it didn't, my pair of operations would basically turn 00000011 into 00001100, which is not a value I need.
This data is stored in a file and may be accessed elsewhere. If the storing machine and the reading machine use different bit orders, the reader will get garbage.

I also don't remember ever reading a piece of code which reacts to the order of bits.

So, my question is: Am I just being paranoid or my C# library could ever be used on an LSB-first machine? (under .NET or Mono; Windows, Unix, Android, iOS, whatever)
If so, how can I efficiently handle the possibilities and be able to retrieve my 2-bit number correctly?

Answer 1

Since you are using things like shift operations: you're fine. Endianness doesn't impact these: they will behave the same on any *-endian architecture - simply: how it works internally may change between CPUs, but you'll always get the same answers, as seen from regular code.

Endianness really only affects direct value-to-bytes interpretations, for example using unsafe code or BitConverter to get (or set) the raw bytes behind an int or a double , an explicit layout "union" struct that overlaps the bytes of different fields. If you aren't doing that type of thing , then you don't need to worry about CPU endianness.

Answer 2

You don't have to worry about the bit order. However the bits are handled in the CPU, the corresponding bit operations work the same to the outside.

When you shift right, that is always towards the least significant bits. If the least significant bit is actually to the left inside the CPU, the physical bits are shifted to the left, but the representation of the number outside the CPU is still with the least significant bit to the right, and the meaning of the operator is the same on any CPU.

When you make a bitwise or with 0xC0 it doesn't matter where the bits are, because the most significant bit in the value and the most significant bit in 0xC0 is in the same place.