572

Why are hexadecimal numbers prefixed as 0x?

I understand the usage of the prefix, but I don't understand the significance of why 0x was chosen.

Improve this question
5
  • 12
    Now I realize that the title and the text ask two entirely different questions. Most replies focus on the question in the title. The answer to the question in the text is simply "it does not mean anything - it is merely a prefix telling the compiler that the integer is written in hexadecimal". Commented Apr 22, 2010 at 23:39
  • 36
    To be pedantic, one might also interpret the question in the title in two different ways: 1) "Why are hexadecimal numbers prefixed as 0x, as opposed to any other prefix or indicator?" 2) "Why do we need to use a prefix when entering hexadecimal numbers? Surely the compiler will recognize 58A as a hexadecimal number even without the prefix?" The answer to the second interpretation of the question is trivial. "123" is also a hexadecimal number. Commented Apr 22, 2010 at 23:42
  • 4
    Why the prefix 0x denotes hex number, instead of 0h? Commented Sep 6, 2021 at 14:35
  • Given that anyone asking this question probably realizes that hex numbers must be distinguished from decimal numbers somehow, it's reasonable to assume he means "why are these particular characters chosen" for hex numbers; not "why do we need a prefix at all." Commented Apr 16 at 16:44
  • Related: Mostly for C: Can I use a binary literal in C or C++?, Why are hexadecimal numbers prefixed with 0x?, Where did the octal/hex notations come from?, What do numbers using 0x notation mean?, Where does 0x come from?, and Writing binary number system in C code Commented Aug 28 at 20:04

5 Answers 5

Reset to default
598

Short story: The 0 tells the parser it's dealing with a constant (and not an identifier/reserved word). Something is still needed to specify the number base: the x is an arbitrary choice.

Long story: In the 1960s, the prevalent programming number systems were decimal and octal — mainframes had 12, 18, 24 or 36 bits per byte, which is nicely divisible by 3 = log2(8).

The BCPL language used the syntax 8 1234 for octal numbers. When Ken Thompson created B from BCPL, he used the 0 prefix instead. This is great because

  1. an integer constant now always consists of a single token,
  2. the parser can still tell right away it's got a constant,
  3. the parser can immediately tell the base (0 is the same in both bases),
  4. it's mathematically sane (00005 == 05), and
  5. no precious special characters are needed (as in #123).

When C was created from B, the need for hexadecimal numbers arose (the PDP-11 had 16-bit words and 8-bit bytes) and all of the points above were still valid. Since octal numbers were still needed for other machines, 0x was arbitrarily chosen (00 or 0h was probably ruled out as awkward).

C# is a descendant of C, so it inherits the syntax.

You can find details about the history of C at Dennis M. Ritchie's page.

Improve this answer
Sign up to request clarification or add additional context in comments.

13 Comments

I don't think 0x over 00 was preference/awkwardness. 00 would break existing code. 0010 as octal is 8, while 0010 as hexidecimal would be 16. They couldn't use any number as a second digit indicator (except 8 or 9, and neither holds any significance related to hexidecimal) so a letter is a must. And that leaves either 0h or 0x (H e X idecimal). From this point it seems it's truly back to preference.
Related: stackoverflow.com/questions/18987911/… and stackoverflow.com/questions/11483216/…
Using a 0 prefix for octal has caused so very many problems over the years. Notably in countries like the UK where telephone numbers start with a 0. Javascript and many other languages would parse these as octal, mangling the number before storing. To add to the fun, one popular database product would silently switch back to decimal parsing if the number contained an 8 or 9.
12, 24 and 36 are also divisible by 4 so why didn't they think of hexadecimal for that?
@LưuVĩnhPhúc Probably because hexadecimal wasn't very relevant. Most of the hardware, software, and documentation of the time fit octal much better. BCPL was first implemented on a 36 bit IBM 7094, with an instruction format split into two 3 bit parts and 2 15 bit parts; 6 bit characters; and documentation in octal. B's early implementations were on a PDP-7 (18 bit) and a Honeywell GE-945 (36 bit, but with 18 bit addressing, and support for 6 and 9 bit bytes). The 16 bit PDP-11 came out after B, so would not have influenced B's design much.
|
125

Note: I don't know the correct answer, but the below is just my personal speculation!

As has been mentioned a 0 before a number means it's octal:

04524 // octal, leading 0

Imagine needing to come up with a system to denote hexadecimal numbers, and note we're working in a C style environment. How about ending with h like assembly? Unfortunately you can't - it would allow you to make tokens which are valid identifiers (eg. you could name a variable the same thing) which would make for some nasty ambiguities.

8000h // hex
FF00h // oops - valid identifier!  Hex or a variable or type named FF00h?

You can't lead with a character for the same reason:

xFF00 // also valid identifier

Using a hash was probably thrown out because it conflicts with the preprocessor:

#define ...
#FF00 // invalid preprocessor token?

In the end, for whatever reason, they decided to put an x after a leading 0 to denote hexadecimal. It is unambiguous since it still starts with a number character so can't be a valid identifier, and is probably based off the octal convention of a leading 0.

0xFF00 // definitely not an identifier!
Improve this answer

7 Comments

Interesting. I imagine they could have used a leading 0 AND trailing h to denote hex. The trailing h probably would have been confused with the type specifier suffix, e.g. 0xFF00l vs 0FF00hl
This argument implies that the use of a leading zero to denote octal numbers predates the use of the hexadecimal "0x" prefix. Is this true?
Wouldn't they have both been invented at the same time? Why would there ever be one but not the other?
AshleysBrain see answer by @Řrřola for why there could be octal but not hexadecimal at the same time.
@zdan they have used it long time ago. In x86 Intel assembly a hex literal must always be prefixed by 0 if they begin with a character. For example 0xFFAB1234 must be written as 0FFAB1234h. I remember it from inline asm in Pascal when I was young stackoverflow.com/q/11733731/995714
|
39

It's a prefix to indicate the number is in hexadecimal rather than in some other base. The programming language uses it to tell the compiler.

Example:

0x6400 translates to 6*16^3 + 4*16^2 + 0*16^1 +0*16^0 = 25600. When the compiler reads 0x6400, it understands the number is hexadecimal with the help of the 0x term. Usually we can understand by (6400)16 or (6400)8 or whatever ..

For binary, it would be:

0b00000001

Improve this answer

2 Comments

Binary literals are only supported in C++ since C++14, and not supported in C at all.
This doesn't explain why. Particularly, why couldn't you write the first example as x6400? The x could still be used to infer hexadecimal.
21

The preceding 0 is used to indicate a number in base 2, 8, or 16.

In my opinion, 0x was chosen to indicate hex because 'x' sounds like hex.

Just my opinion, but I think it makes sense.

Good Day!

Improve this answer

3 Comments

Thanks for the answer! I understand that this is your first post on StackOverflow. The answer could have been more helpful if opinions are separated from facts.
This answer does a great job of separating opinions from facts.
I appreciate the very plausible idea that "x" rhymes with "hex" which is a common way to refer to a hexadecimal number. This is the only answer that mentions it.
14

I don't know the historical reasons behind 0x as a prefix to denote hexadecimal numbers - as it certainly could have taken many forms. This particular prefix style is from the early days of computer science.

As we are used to decimal numbers there is usually no need to indicate the base/radix. However, for programming purposes we often need to distinguish the bases from binary (base-2), octal (base-8), decimal (base-10) and hexadecimal (base-16) - as the most commonly used number bases.

At this point in time it is a convention used to denote the base of a number. I've written the number 29 in all of the above bases with their prefixes:

  • 0b11101: Binary
  • 0o35: Octal, denoted by an o
  • 0d29: Decimal, this is unusual because we assume numbers without a prefix are decimal
  • 0x1D: Hexadecimal

Basically, an alphabet we most commonly associate with a base (e.g. b for binary) is combined with 0 to easily distinguish a number's base.

This is especially helpful because smaller numbers can confusingly appear the same in all the bases: 0b1, 0o1, 0d1, 0x1.

If you were using a rich text editor though, you could alternatively use subscript to denote bases: 12, 18, 110, 116

Improve this answer

3 Comments

Why 0h is not chosen for hex? 0x seems strange.
@DawnSong It's just a convention that is quite popular and now we have to live with it. Sometimes these things are arbitrary. You could try promoting your way, but it's hard to change the habits of so many people. I find the Octal one to be the most confusing visually.
Except that in the '70s and '80s, people learned that hex numbers were prefixed with $. I never saw "0x" until I got to IBM-compatibles.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.