Question

I’m a beginner in C and I have a statement like:

printf("%d",(1^6));

which produces answer as 7. I know ^ is the xor operator. I assume here, 1 is represented in 4 bits like 0001 and 6 as 0110. Doing xor yields the result as 0111 which is 7.

Is that my assumption is correct? In C language how numbers are represented internally?

Thanks in advance.

Answer 1

There are two slightly different things to consider here.

The C language standard says that the literals 1 and 6 have type int, and that the XOR operation will therefore be performed using the int type.

The C language standard also says that the int type has a binary representation, with value bits running from least to most significant in increasing powers of 2, plus a sign bit which isn’t relevant here because the numbers are both positive, plus optionally some padding bits (and I’ve never used a C implementation that had any padding bits in int).

So in those terms, you’re right: 1 is represented as binary 1, 6 is represented as binary 110, 7 is 111, plus there are initial 0s sufficient to make up the size of the type int. When writing a binary number we rarely bother to write 00000000000000000000000000000001 even when we know its type is 32 bits.

The number of value+sign bits in an int is 32 in most implementations. You might occasionally see 64 or even 16. The standard requires at least 16, but past that it permits any number.

An int usually occupies more than one byte of storage. The standard doesn’t say whether the least significant bits occupy the first (lowest-addressed) byte, or the last (highest-addressed), or somewhere in the middle. So it allows both little-endian and big-endian representations, and in theory also “middle-endian” representations (I’ve never seen one of those either, at least not for int). Endian-ness relates to the representation of the int in memory, but it’s irrelevant to the bitwise operations (including XOR), which are defined in terms of the bits in order of significance, not in terms of their order in memory.

That’s all in the standard, but the standard also says that it only describes the behavior of an “abstract machine”. What your compiler actually does is required to have the same result as what the standard says, but there’s no requirement for any given code snippet that you’ll see those exact representations in memory when the program runs. It would be perfectly legal for a compiler to emit the same code for your line as it would emit for printf("7"); or even fputc('7', stdout);, if it wants to. So there might not be any representation of 1 in the emitted code.

Maybe it will only optimize as far as printf("%d", 7);, if printf is implemented part of a library and the compiler doesn’t bother anticipating what "%d" means to that library. Maybe it will do the calculation at runtime, but represent 1 however it thinks is most compact and/or efficient for the target CPU, as long as the compiler has first proved to its own satisfaction that a different size will produce the same result. For example, some instruction sets allow so-called “immediate values”, which are small integers stored as part of an instruction. The representation of 1 would still be some number of 0s with a 1 at the end, but because immediates have to fit inside an instruction they’ll generally be smaller than int.

The exact details of this kind of thing depend on your compiler, target architecture, optimization level, and possibly other compiler options.