3

I'm on pset 4 recover and stuck, trying to understand the bitwise operator, if (buffer[3] & 0xf0) == 0xe0) Can someone tell me if my understanding is correct? The if condition checks the value at buffer[3] value, and then uses the bitwise operator to compare the bitmask (0xf0) and then checks if the result is 0xe0.

1111 0000 (0xf0)

1110 0000 (0xe0)

1110 0000 (0xe00)

This is the math, I understand this, but I don't see how this if condition checks all the possible values for the fourth byte in the jpg 0xe0, 0xe1, 0xe2, 0xe3, 0xe4, 0xe5, 0xe6, 0xe7, 0xe8, 0xe9, 0xea, 0xeb, 0xec, 0xed, 0xee, of 0xef

Improve this question
  • Como lo entiendo la condición (tampón [3] y 0xF0) devolverá 0xE0 mientras buffer [3] es entre 0xE0 a 0xEF, You do not need to check each value individually so that the condition returns a valid byte for all those possible values, a good trick, right? – MARS Jun 11 '17 at 10:27
8

The bitwise AND operator does exactly what it sounds like, it looks at each bit at the same position in each of the two values and ANDs them. That means that if both bits are 1, then the result is 1. If either or both bits are 0, the result is 0.

Now, consider that the buffer[3] is being bitwise ANDed to 0xf0. Let's split that into two parts. You have two half-bytes, F and 0, or 1111 and 0000. If you look closely at that, it means that the first 4 bits from buffer[3] are preserved and the second 4 bits become 0.

Why is this important? We want to check that the first half-byte is E or 1110, but the second half-byte can be anything. Since we ANDed with 0000, the second half-byte result is 0, a single value to check, and the first half-byte is preserved.

So, with all that, we need only check that the result of the bitwise AND operation is 0xE0.

Hopefully, that makes sense.

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

Improve this answer
  • You say that the first byte of buffer[3] is preserved, but if we test it with 1111 0000 to the 0xe0 1110 0000 wouldn't the result be just 1110 0000? Is 0xf0 not one byte ? or is it two bytes? F and 0 I thought as bytes are 8, one of these hexa decimal values is one byte. – Jake Jun 12 '17 at 15:16
  • Sorry, my mistake. You are correct, a byte is 8 bits. The first 4 bits would be preserved and the second 4 bits would be masked to 0. I'll correct that now. – Cliff B Jun 12 '17 at 18:35
  • I have the same question, though did not completely understand the answer. Cliff said "Let's split that into two parts. You have two half-bytes, F and 0, or 1111 and 0000. If you look closely at that, it means that the first 4 bits from buffer[3] is preserved and the second 4 bits become 0." I did not understand this point. I did understand that we are looking for the bits 1110 [the e] followed by [any four bits representing the hexadecimal from 1 to f]. I don't see how this checks all the possible values in the fourth JPEG byte. – Haim Jun 18 '17 at 23:18
  • The last 4 bits don't matter (any value is valid). By doing a bitwise AND with 0, it sets all bits to 0 in the result (this is called masking the bits), giving us a known value to compare that half-byte with, specifically, 0. To be clear, we just don't care about the last 4 bits, since all 16 possible values are valid. BUT, we do need to make sure that they don't affect the comparison of the first 4 bits, so we need to have something in there. Now, the first 4 bits. By doing a bitwise AND with 1111, or F in hex, it means that whatever is being tested will be preserved for checking against E. – Cliff B Jun 18 '17 at 23:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .