smilingbuddha
smilingbuddha

Reputation: 14660

Binary representation in C

In C why is there no standard specifier to print a number in its binary format, sth like %b. Sure, one can write some functions /hacks to do this but I want to know why such a simple thing is not a standard part of the language.

Was there some design decision behind it? Since there are format specifiers for octal %o and %x for hexadecimal is it that octal and hexadecimal are somewhat "more important" than the binary representation.

Since In C/C++ one often encounters bitwise operators I would imagine that it would be useful to have %b or directly input a binary representation of a number into a variable (the way one inputs hexadecimal numbers like int i=0xf2 )

Note: Threads like this discuss only the 'how' part of doing this and not the 'why'

Upvotes: 9

Views: 6542

Answers (5)

Guest-11
Guest-11

Reputation: 1

I agree. I was a participant in the original ANSI C committee and made the proposal to include a binary representation in C. However, I was voted down, for some of the reasons mentioned above, although I still think it would be quite helpful when doing, e.g., bitwise operations, etc.

It is worth noting that the ANSI committee was for the most part composed of compiler developers, not users and C programmers. Their objectives were to make the standard understandable to compiler developers not necessarily for C programmers, and to be able to do so with a document that was no longer than it need be, even if this meant it was a difficult read for C programmers.

Upvotes: 0

tobyodavies
tobyodavies

Reputation: 28089

The main reason as I see it is what binary representation should one use? one's complement? two's complement? are you expecting the actual bits in memory or the abstract number representation?

Only the latter makes sense when C makes no requirements of word size or binary number representation. So since it wouldn't be the bits in memory, surely you would rather read the abstract number in hex?

Claiming an abstract representation is "binary" could lead to the belief that -0b1 ^ 0b1 == 0 might be true or that -0b1 | -0b10 == -0b11


Possible representations:

While there is only one meaningful hex representation --- the abstract one, the number -0x79 can be represented in binary as:

  • -1111001 (the abstract number)
  • 11111001 (one's complement)
  • 10000111 (two's complement)

@Eric has convinced me that endianness != left-to-right order...

the problem is further compounded when numbers don't fit in one byte. the same number could be:

  • 1000000001111001 as a one's-complement big-endian 16bit number
  • 1111111110000111 as a two's-complement big-endian 16bit number
  • 1000011110000000 as a one's-complement little-endian 16bit number
  • 1000011111111111 as a two's-complement little-endian 16bit number

The concepts of endianness and binary representation don't apply to hex numbers as there is no way they could be considered the actual bits-in-memory representation.

All these examples assume an 8-bit byte, which C makes no guarantees of (indeed there have been historical machines with 10 bit bytes)


Why no decision is better than any decision:

Obviously one can arbitrarily pick one representation, or leave it implementation defined. However:

  • if you are trying to use this to debug bitwise operations, (which I see as the only compelling reason to use binary over hex) you want to use something close what the hardware uses, which makes it impossible to standardise, so you want implementation defined.
  • Conversely if you are trying to read a bit sequence, you need a standard, not implementation defined format.
  • And you definitely want printf and scanf to use the same.

So it seems to me there is no happy medium.

Upvotes: 2

Raymond Hettinger
Raymond Hettinger

Reputation: 226171

You ask "why" as if there must be a clear and convincing reason, but the reality is that there is no technical reason for not supporting a %b format.

K&R C was created be people who framed the language to meet what they thought were going to be their common use cases. An opposing force was trying to keep the language spec as simple as possible.

ANSI C was standardized by a committee whose members had diverse interests. Clearly %b did not end-up being a winning priority.

Languages are made by men.

Upvotes: 3

Jonathan Leffler
Jonathan Leffler

Reputation: 753455

The main reason is 'history', I believe. The original implementers of printf() et al at AT&T did not have a need for binary, but did need octal and hexadecimal (as well as decimal), so that is what was implemented. The C89 standard was fairly careful to standardize existing practice - in general. There were a couple of new parts (locales, and of course function prototypes, though there was C++ to provide 'implementation experience' for those).

You can read binary numbers with strtol() et al; specify a base of 2. I don't think there's a convenient way of formatting numbers in different bases (other than 8, 10, 16) that is the inverse of strtol() - presumably it should be ltostr().

Upvotes: 3

kol
kol

Reputation: 28678

One answer may be that hexadecimal formatting is much more compact. See for example the hexa view of Total Commander's Lister.

%b would be useful in lots of practical cases. For example, if you write code to analyze network packets, you have to read the values of bits, and if printf would have %b, debugging such code would be much easier. Even if omitting %b could be explained when printf was designed, it was definitely a bad idea.

Upvotes: 1

Related Questions