I'm working on a library that supports file reading, and right now I've always assumed that all the bytes are written in most significant bit first format. Is the least significant bit first format ever practically used anywhere today on any platform? The library I'm writing isn't targeted at older operating systems (ideally anything onwards from the year 2000).

I'm curious if writing such a feature in might be a waste of time that could be spent on other things.

  • 4
    As far as I know, "least significant bit" is merely a name for the bit in a word with the smallest positional value. I am not aware of any "format" or encoding that goes by that name. Are you perhaps confusing this with the terms big endian and little endian? – user7043 Mar 3 '15 at 21:55
  • 6
    Little Endian vs. Big Endian is about byte order, not bit order! The smallest addressable unit is usually a byte or a word, and the data inside this unit is just an opaque number. The position of single bits cannot be determined and is not relevant. A byte will have a least significant bit and a most significant bit, but the question of which bit comes first, is mu, is empty. – amon Mar 3 '15 at 22:06
  • 2
    Big endian byte order is used EVERYWHERE - not just natively on certain non-x86 architectures like SPARC, but also every time you transmit binary data over a network. DNS, HTTP 2.0, and many other standards transmit integers in network byte order ("big endian"), meaning that any program which implements or deals with such protocols must deal with big endian format. – Charles Salvia Mar 3 '15 at 22:20
  • 4
    I don't know why people are bringing up little/big endian byte order. My question is about bit order, not byte order. I already know and have written stuff for little/big endian. Edit: This is directed at the people that are confused if I'm asking about byte order. – Water Mar 3 '15 at 22:39
  • 5
    Within the scope you set, there is no bit-order, as the data is written in chunks of bytes. – Deduplicator Mar 3 '15 at 23:11

Well, you might have heard of a little thing called Ethernet, which transmits most-significant byte first, but least-significant bit first.

The thing is, no one cares unless they happen to be designing an Ethernet card, because the card's hardware packs the data into bytes, which is how it's accessed everywhere else in the system.

So if your library happens to be designed to run directly on a disk drive controller chip, and you have to read data written by other controllers following their own standards, by all means include the option. Anywhere else, it doesn't matter.

| improve this answer | |

If you are looking for a very precise answer, you will need to define very precisely what "least significant bit format" means. As evident in the comments, there can be a lot of interpretations of what that means, and a lot of details can be glossed over by a not very careful reader.

Example #1 - BMP image format, for black-white (1bpp)

For one example of "least significant bit first format", consider the BMP image format, 1bpp.

A black and white (bitonal, or 1-bit-per-pixel) image stored as BMP will have its row-zero, column-zero pixel stored at the bit 7 of the byte 0 of the pixel data area.

As a matter of arithmetic, the term "bit 7" always unambiguously refer to the bit mask 0x80, because it is the "7th digit of its binary representation". (the 0th digit is the bit mask 0x01.)

Example #2 - TIFF Fax


The original TIFF Fax specification was designed with hardware (electronic) implementations in mind, and therefore has to deal with electrical serialization and deserialization. With it comes the choice of which bit to send down the wire first. Thus, the specification allows for both, and therefore every TIFF image reader has to support reading both kinds of files and to perform the necessary conversion before decoding the bit stream.

| improve this answer | |
  • 1
    Good examples. Of course, those image format decoders are unlikely to expect the file io library to perform the reversal. – Karl Bielefeldt Mar 3 '15 at 23:19
  • @KarlBielefeldt one would not expect the File IO to have these utilities, but would certainly expect them in an Endianness utility or a Bit Array utility. In particular, bit endianness must also be considered in conjunction with bit-packing (such as used in Huffman code ) - one will need to read "7 bits", with a particular bit-endianness, and which straddles two bytes (i.e. not aligned or confined by byte boundaries). It all depends on needs and specification. – rwong Mar 3 '15 at 23:32
  • Agreed. Oh, the perils of a vaguely-specified question :-) – Karl Bielefeldt Mar 4 '15 at 0:30

Given that things such as characters / letters, numbers, and raw in essentially every format and programming language use the most significant bit first format, you can apply the ostrich solution to this problem. Your time is better spent working on the actual library itself instead of a feature that will likely never be needed.

Also, as some people have mentioned, a decent amount of integers that use the least-significant-* format use the most-significant-byte format which is a different thing.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.