why it shows like this in hexadecimal notation? - c

Question

I'm trying to do bit arithmetic with variables a and b. When I reverse a, which has the value 0xAF, the result shows as 8 digits.
Unlike the others that show as 2 digits.
I don't know why it happens, but guess that it is relevant to %x's showing way and little endian?
Here is my code:
#include <stdio.h>
int main()
{
int a = 0xAF; // 10101111
int b = 0xB5; // 10110101
printf("%x \n", a & b); // a & b = 10100101
printf("%x \n", a | b); // a | b = 10111111
printf("%x \n", a ^ b); // a ^ b = 00011010
printf("%x \n", ~a); // ~a = 1....1 01010000
printf("%x \n", a << 2);// a << 2 = 1010111100
printf("%x \n", b >> 3); // b >> 3 = 00010110
return 0;
}

Answer 1

Considering your int a is most likely 32 bit in size, your a actually looks like this:
int a = 0xAF; // 0000 0000 0000 0000 0000 0000 1010 1111
So if you flip all the bits on that, you have
1111 1111 1111 1111 1111 1111 0101 0000
Or, in hex
0xFFFFFF50
Which is exactly what you're getting. The others show only 2 digits because trailing zeroes are omitted when printing hex, and your other bit operations do not in fact change any of the leading zeroes.
---- Credit to # chqrlie for this ----
If you really only want to see 8 bits of the result, you can do
printf("%hhx \n", ~a); // ~a = 1....1 01010000 --> Output : 50
Which restricts the printed value to unsigned char (8 bit [on modern os, not guaranteed, but very likely for your purposes]) length.

Answer 2

There's a lot of potential problems with code like this.
Most importantly, you should never use signed integer types like int when doing bitwise operations. Because you could either end up with unexpected results, or you could end up with undefined/implementation-defined behavior bugs if using operators like << >> on negative value integers.
So step one is to ensure you have an unsigned integer type. Preferably uint32_t or similar from stdint.h.
Another related problem is that if you use small integer types in an expression, such as uint8_t, char, short, bool etc, then they will get implicitly promoted to type int, which is a signed type. You get that even if you use unsigned char or uint8_t. This is the source of many fatal bugs related to the bitwise operators.
And finally, the printf family of functions is dangerous to use when you need to be explicit about types. While these function have literally zero type safety, they at the same time assume a certain, specific type. If you give them the wrong type you invoke undefined behavior and the program will potentially crash & burn. Also, being variable-argument list functions, they also use implicit promotion of the arguments (default argument promotions) which might also cause unforeseen bugs.
The "strange" output you experience is a combination of doing bitwise ~ on a signed type and printf expecting an unsigned int when you give it the %x conversion specifier.
In order to get more deterministic output, you could do something like this:
#include <stdio.h>
#include <inttypes.h>
int main()
{
uint32_t a = 0xAF; // 10101111
uint32_t b = 0xB5; // 10110101
printf("%.8" PRIx32 "\n", a & b); // a & b = 10100101
printf("%.8" PRIx32 "\n", a | b); // a | b = 10111111
printf("%.8" PRIx32 "\n", a ^ b); // a ^ b = 00011010
printf("%.8" PRIx32 "\n", ~a); // ~a = 1....1 01010000
printf("%.8" PRIx32 "\n", a << 2); // a << 2 = 1010111100
printf("%.8" PRIx32 "\n", b >> 3); // b >> 3 = 00010110
return 0;
}