Bitwise Operators Questions and Answers

Answer: A

Correct answer: True

A power of two has exactly one bit set, so clearing its lowest set bit leaves nothing. Any value with two or more bits set retains the higher ones, giving a non-zero result, which is why the test must also exclude n = 0.

Answer: A

Correct answer: true 2

& is the bitwise AND, so unlike && it does not short-circuit and both operands are evaluated. The assignment sets y to 2 and yields 2, so the test is a non-zero value and the true branch runs, printing the current value of y, which is now 2.

One caution is worth stating: reading y in the left operand is unsequenced with respect to the assignment in the right, which the C standard leaves undefined. Compilers in practice produce true 2, but the expression is one to recognise as badly formed rather than to imitate.

Answer: A

Correct answer: ffff

\( -1 \) in two's complement is all ones, so on a 2-byte int it is 0xffff.

Right-shifting a signed negative value is implementation-defined, and every common compiler performs an arithmetic shift, propagating the sign bit into the vacated position. All ones shifted right with ones coming in is still all ones, so the result is unchanged at 0xffff, which %x prints as ffff.

Had the shift been logical, a zero would have entered at the top and the answer would have been 7fff. That difference is exactly why shifting negative values is best avoided in portable code.

Answer: A

Correct answer: Yes

This is the standard idiom for clearing bits. ~ inverts a mask so that the positions of interest hold 0 and everything else holds 1; AND then forces those positions to 0 and leaves the rest untouched.

So n &= ~0x02 clears bit 1, and n &= ~(0x02 | 0x08) clears two bits at once - the technique extends to as many as the mask names. It is the exact counterpart of n |= mask for setting bits, and the pair covers most bit manipulation in practice.

Answer: B

Correct answer: 29

OR compares the two numbers bit by bit and keeps a 1 where either has one:

  13 = 0 1 1 0 1
  25 = 1 1 0 0 1
  --------------
   |  = 1 1 1 0 1

The result 11101 is \( 16 + 8 + 4 + 1 = 29 \).

A useful check: OR can never produce a value smaller than either operand, since it only ever turns bits on, so an answer below 25 would be wrong on inspection alone. That rules out 9 - which is what & gives - and 20, which is ^, without any arithmetic.

Answer: A

Correct answer: yes

The trap is precedence: ! binds tighter than ==, so the expression parses as (!0) == 1, not as !(0 == 1).

The logical NOT of zero is 1 by definition - C's relational and logical operators yield exactly 0 or 1 - so the test becomes 1 == 1, which is true, and yes is printed. Note that x is never used at all; declaring it is a distraction. Even the other reading would have given the same result here, since 0 == 1 is false and !false is true.

Answer: C

Correct answer: 15

The literal 0xF0 is 11110000 in binary - the high four bits of the byte set, the low four clear. Shifting right by four moves every bit four places towards the least significant end, so those four ones land in the low nibble and the vacated positions are filled with zeros: 00001111, which is \( 8+4+2+1 = 15 \), or 0x0F.

The shorthand is that a right shift by \( n \) divides by \( 2^{n} \), and here \( 240 / 16 = 15 \).

The type matters. Because c is unsigned, the vacated high bits are guaranteed to be filled with zeros. On a signed type holding a negative value the standard leaves the fill implementation-defined, and most compilers propagate the sign bit instead - which is why bit manipulation is normally done on unsigned types. The distractor 240 is the value of c itself, left unshifted.

Answer: C

Correct answer: 32, 32, 32, 32, 0

Start with the observation that hides the whole question: 0x20 is 32 in decimal, so i and j hold the same value.

Then each identity applies. \( x \mathbin{|} x = x \) gives \( k = 32 \); \( x \mathbin{\&} x = x \) gives \( l = 32 \); and \( x \mathbin{\hat{}} x = 0 \) gives \( m = 0 \). Printed in order the values are 32, 32, 32, 32, 0. Recognising that a hex literal and a decimal one denote the same number is the step the question is really testing.

Answer: D

Correct answer: 2 3 3

Take the two statements in order. y = --x is a pre-decrement: x becomes 3 first and that new value is assigned, so y is 3.

z = x-- is a post-decrement: the current value 3 is assigned to z, and only then does x become 2. At the printf the variables are \( x = 2 \), \( y = 3 \), \( z = 3 \), printed in that order as 233. The whole question turns on which value the expression yields - the new one for a prefix operator, the old one for a postfix.

Answer: B

Correct answer: No

Bitwise operators are entirely deterministic: the same operands always give the same result, so nothing about them produces randomness.

A pseudo-random generator needs persistent state, a seed and an algorithm chosen so that successive outputs pass statistical tests. Some well-known generators - the xorshift family - are indeed built from XOR and shifts, but the randomness comes from the algorithm and the seed, not from the operators, which are only the arithmetic it happens to use.