# Can't seem to wrap my head around what the Bitwise AND operator does in Pset4 vs. && AND operator

I just watched the Recover video and I saw them mention bitwise arithmetic, but I am not exactly sure what that means nor what it does. I saw another forum post explain it but that also didn't really get the concept through to me either. The explanation kinda went over my head a bit. The code they showed was `(buffer & 0xF0) == 0xe0`. Could anyone explain 1)What the `&` is doing here and 2) and 2)Why we are using `0xF0`.

Much appreciated!

• Does this answer your question? pset 4 recover - Bitwise operator Jul 30 '20 at 19:05
• I'm still lost on why we use the 0xF0 at all? I have a sense of what & does, but how is it different from && ? Jul 30 '20 at 19:22

OK, your comment changes the context of the question. So let's get into the differences.

The && operator says " A && B" means take these two values and combine them. If both are true, then the whole is true. Otherwise, it's false. Remember too that any integer other than 0, is evaluated as true. This includes negative numbers. If neither A nor B are equal to 0, the result of this would be true.

The bitwise & operator is far more specific. It says "look at the individual bits in two variables/bytes/whatever and generate a result based on comparing the bits.

So let's say that A = 1010 1111 or 0xAF and B = 1100 0011 or 0x93

Now, let's do A & B. It means to compare the individual bits. If they're both 1 (since 1 AND 1 is 1), then the result is 1. Otherwise, 0 (0 AND 1 is 0 and 0 AND 0 is 0).

So, the result looks like this. Remember, the bits here are being compared vertically.

``````1010 1111
1100 0011
---- ----
1000 0011 = 0x83
``````

Now, let's get into "masking'. Say that you want to look at certain values but don't care about other values or want to hide them. If you use a bitwise or operation, &, then you can preserve a bit value by comparing it with 1 and force a value to 0 by comparing it to 0.

In the case of pset4, we want to check the value of the first 4 bits in buffer. Since any value for the second 4 bits is ok, we want a way to "don't care" but still be able to do the final comparison of the result to something.

So, if we bitwise AND, &, the first 4 bits with 1111, or hexadecimal F, the generated result will be whatever is in the first 4 bits in buffer. At the same time, if we & the last 4 bits with 0000 or hex 0, the result MUST be 0000. So, by doing `(buffer & 0xF0) == 0xe0` then we're comparing the first 4 bits to `E` and we're forcing the last 4 bytes (that we don't care about) to 0 so that we can finish the comparison.

Any questions? ;-)

If this answers your question, please click on the check mark to accept. Let's keep up on forum maintenance ;-)

• Thanks a lot! The little diagram helped a bunch, and sorry my original question didn't state my issue properly haha Jul 30 '20 at 20:23

Simply we are comparing bits to make sure are the same for our required pattern

our pattern is 0xe0 or 0xe1 or 0xe2 and so on... so ignore 1 - 2 - 3 - 4 - ... a - f we can make sure to have the right pattern by just checking 0xe

e is the first four bits of the byte

if buffer contains the pattern 0xe we are finding what we are looking for in other words the pattern for the jpeg

Bitwise help us to compare:

The ideal 4 bit from buffer would have 0xe

Our expression is: `(buffer & 0xf0) == 0xe0`

Convert everything to binary and then let's compare:

0xe to binary: 1110 AND 0xf0 to binary: 11110000

forget 0x and let's focus on e and f: e has 4 bits and f has 4 bits

comparing bits:

1 & 1 == 1

1 & 1 == 1

1 & 1 == 1

0 & 1 == 0

So this comparing is equals to 1110 or in hex 0xe

Rules are simple 1 & 1 turns to be 1 AND 0 & 1 turns to be 0

Going back to our expression:

``````(buffer & 0xf0) == 0xe0
``````

1110 & 1111 IS INDEED 1110 WHICH IS 0xe and 0

1110 & 1111 is the same as 0xe0

So we just compared and found an ideal pattern where buffer & mask (0xf0) is 0xe0 there for we just found a jpeg

It's clear what happens when you transform everything to binary from hex I hope this helps to understand this expression.