Q: Bit masking and shifts in C: evaluate the expression and print the result. #include int main() { unsigned int res; res = (64 >>(2 + 1 - 2)) & (~(1 << 2)); printf("%d ", res); return 0; }

Introduction / Context: This exercise evaluates operator precedence, arithmetic inside shift counts, and bit masking using complement and bitwise AND. It is a classic quick check of bit-twiddling fluency. Given Data / Assumptions: All operations occur on unsigned int. 64 in binary is 1 at bit 6 (counting from bit 0), i.e., 0b0100 0000. 1 > 1 = 32 (binary 0b0010 0000).Form mask: ~(1 << 2) = ~4. In binary, this is all ones except bit 2 is zero.AND: 32 & ~4 = 32 because bit 2 of 32 is not set.printf prints 32. Verification / Alternative check: Write the numbers in binary to see that only bit 5 is set after shifting, while the mask only clears bit 2, leaving 32 unaffected. Why Other Options Are Wrong: 64 would require no shift. 0 or 28 would require clearing bit 5, which the mask does not do. 128 would require a left shift or a different starting value. Common Pitfalls: Miscounting shift precedence vs addition/subtraction; forgetting that ~ affects all bits, not just the low nibble; confusing decimal with binary positions. Final Answer: 32

Q: ASCII and bitwise OR on character codes: what five characters are printed? #include int main() { char c = 48; // ASCII '0' int i, mask = 01; // octal 1 for (i = 1; i <= 5; i++) { printf("%c", c | mask); mask = mask << 1; } return 0; }

Introduction / Context: This problem blends ASCII knowledge with bitwise operations. The code ORs the code for '0' (48, hex 0x30) with a mask that shifts left each iteration, then prints the resulting character. Recognizing which bit patterns map to digit characters helps. Given Data / Assumptions: ASCII '0' is 48 → binary 0x30 → 0011 0000. The mask starts at 1 (0000 0001) and shifts left by 1 each loop. Five iterations produce five characters. Concept / Approach: ORing sets bits present in either operand. Since 0x30 already has bits 4 and 5 set, ORing with 1, 2, 4, 8, and 16 selectively toggles the low nibble while sometimes leaving the value unchanged if that bit is already 1. Step-by-Step Solution: Iter 1: mask=1 → 0x30 | 0x01 = 0x31 → '1'.Iter 2: mask=2 → 0x30 | 0x02 = 0x32 → '2'.Iter 3: mask=4 → 0x30 | 0x04 = 0x34 → '4'.Iter 4: mask=8 → 0x30 | 0x08 = 0x38 → '8'.Iter 5: mask=16 → 0x30 | 0x10 = 0x30 (bit already set) → '0'. Verification / Alternative check: Print numeric values instead of %c to verify hex codes: 49, 50, 52, 56, 48 correspond to '1', '2', '4', '8', '0'. Why Other Options Are Wrong: '12400', '12500', and '12556' assume different OR results; only the 4th and 5th steps can yield '8' and '0' respectively given the initial 0x30. '13480' incorrectly predicts the third character. Common Pitfalls: Assuming left shifts always increase the printed digit; forgetting that OR with an already-set bit leaves the value unchanged (hence the final '0'). Final Answer: 12480

Q: Bit shifts with negative counts in C: determine the safest conclusion about this program’s outputs (assume typical hosted C, int is 32 bits).\n\n#include \n\nint main()\n{\n printf("%d %d\n", 32<<1, 32<<0);\n printf("%d %d\n", 32<<-1, 32<<-0…

Introduction / Context: This question gauges knowledge of defined vs. undefined behavior for bit shifts in C. While shifting by nonnegative counts is defined, any negative shift count leads to undefined behavior, meaning the program has no guaranteed result. Given Data / Assumptions: 32 >1 and 32>>0 are well-defined: 16 and 32. 32 >-1 have negative shift counts → undefined behavior. -0 is just 0, so shifts by -0 behave like 0 and are defined. Concept / Approach: Per the C standard, shifting by a negative count is undefined. Compilers may produce any result, crash, or optimize strangely. Therefore, any option claiming specific numeric values for those lines is unreliable; the safe, standard-aware answer is that outputs are indeterminate for the lines with negative counts. Step-by-Step Solution: Line 1: prints 64 32.Line 2: first shift is undefined; second is 32.Line 3: prints 16 32.Line 4: first shift is undefined; second is 32. Verification / Alternative check: Different compilers or optimization levels may show different numbers or traps for negative shifts, proving the behavior is not portable. Why Other Options Are Wrong: Any fully specified numeric sequence asserts a defined outcome for the negative shifts, which is not portable or guaranteed. Common Pitfalls: Assuming negative shifts “wrap” or always return 0; writing code that relies on compiler-specific extensions. Final Answer: Garbage values

Question 1

Assume 16-bit signed int: what hexadecimal is printed for this arithmetic right shift?  #include<stdio.h>  int main() { printf("%x ", -1 >> 1); return 0; }

Accepted Answer

Introduction / Context: This question probes your understanding of right-shifting negative signed integers on a 16-bit implementation, and of how printf prints hexadecimal using %x. The key idea is arithmetic right shift on two’s-complement values. Given Data / Assumptions: Assume int is 16 bits and two’s complement. -1 in two’s complement is 0xFFFF. Most compilers implement right shift of signed negative values as an arithmetic shift (propagating the sign bit). Concept / Approach: An arithmetic right shift fills in with the sign bit (1 for negative numbers). Shifting 0xFFFF right by any number of positions preserves all ones. Therefore, -1 >> 1 remains 0xFFFF when interpreted as a 16-bit signed arithmetic shift. Printing with %x emits lowercase hexadecimal without leading 0x. Step-by-Step Solution: Represent -1 → 0xFFFF.Perform arithmetic shift right by 1 → 0xFFFF (ones shift in).printf("%x", 0xFFFF) → prints ffff. Verification / Alternative check: Many compilers document that right shift of negative signed integers is implementation-defined, but on mainstream targets it is arithmetic. If it were a logical shift, the result would be 0x7FFF; the question’s 16-bit assumption targets the common arithmetic behavior. Why Other Options Are Wrong: 0fff and fff0 do not correspond to a one-bit arithmetic right shift of all ones. 0000 is impossible for -1 >> 1 under arithmetic shifting. 7fff would be a logical right shift, not typical for signed. Common Pitfalls: Confusing logical vs arithmetic shifts; forgetting integer size assumptions; overlooking that %x prints unsigned representation of the resulting bit pattern. Final Answer: ffff

Question 2

Bit masking and shifts in C: evaluate the expression and print the result. #include int main() { unsigned int res; res = (64 >>(2 + 1 - 2)) & (~(1 << 2)); printf("%d ", res); return 0; }

Accepted Answer

Introduction / Context: This exercise evaluates operator precedence, arithmetic inside shift counts, and bit masking using complement and bitwise AND. It is a classic quick check of bit-twiddling fluency. Given Data / Assumptions: All operations occur on unsigned int. 64 in binary is 1 at bit 6 (counting from bit 0), i.e., 0b0100 0000. 1 << 2 is 4, whose binary has only bit 2 set. Concept / Approach: We first evaluate the shift count: 2 + 1 - 2 = 1, so the right shift is by 1. Then we apply a mask that clears bit 2 and preserves all others via bitwise NOT of 4. Finally, we AND the shifted value with that mask. Step-by-Step Solution: Compute shift count: 2 + 1 - 2 = 1.Shift: 64 >> 1 = 32 (binary 0b0010 0000).Form mask: ~(1 << 2) = ~4. In binary, this is all ones except bit 2 is zero.AND: 32 & ~4 = 32 because bit 2 of 32 is not set.printf prints 32. Verification / Alternative check: Write the numbers in binary to see that only bit 5 is set after shifting, while the mask only clears bit 2, leaving 32 unaffected. Why Other Options Are Wrong: 64 would require no shift. 0 or 28 would require clearing bit 5, which the mask does not do. 128 would require a left shift or a different starting value. Common Pitfalls: Miscounting shift precedence vs addition/subtraction; forgetting that ~ affects all bits, not just the low nibble; confusing decimal with binary positions. Final Answer: 32

Question 3

ASCII and bitwise OR on character codes: what five characters are printed?  #include<stdio.h>  int main() { char c = 48; // ASCII '0' int i, mask = 01; // octal 1 for (i = 1; i <= 5; i++) { printf("%c", c | mask); mask = mask << 1; } return 0; }

Accepted Answer

Introduction / Context: This problem blends ASCII knowledge with bitwise operations. The code ORs the code for '0' (48, hex 0x30) with a mask that shifts left each iteration, then prints the resulting character. Recognizing which bit patterns map to digit characters helps. Given Data / Assumptions: ASCII '0' is 48 → binary 0x30 → 0011 0000. The mask starts at 1 (0000 0001) and shifts left by 1 each loop. Five iterations produce five characters. Concept / Approach: ORing sets bits present in either operand. Since 0x30 already has bits 4 and 5 set, ORing with 1, 2, 4, 8, and 16 selectively toggles the low nibble while sometimes leaving the value unchanged if that bit is already 1. Step-by-Step Solution: Iter 1: mask=1 → 0x30 | 0x01 = 0x31 → '1'.Iter 2: mask=2 → 0x30 | 0x02 = 0x32 → '2'.Iter 3: mask=4 → 0x30 | 0x04 = 0x34 → '4'.Iter 4: mask=8 → 0x30 | 0x08 = 0x38 → '8'.Iter 5: mask=16 → 0x30 | 0x10 = 0x30 (bit already set) → '0'. Verification / Alternative check: Print numeric values instead of %c to verify hex codes: 49, 50, 52, 56, 48 correspond to '1', '2', '4', '8', '0'. Why Other Options Are Wrong: '12400', '12500', and '12556' assume different OR results; only the 4th and 5th steps can yield '8' and '0' respectively given the initial 0x30. '13480' incorrectly predicts the third character. Common Pitfalls: Assuming left shifts always increase the printed digit; forgetting that OR with an already-set bit leaves the value unchanged (hence the final '0'). Final Answer: 12480

Question 4

Operator precedence with bitwise and logical operators: predict the three integers printed.  #include<stdio.h>  int main() { int i = 4, j = 8; printf("%d, %d, %d ", i | j & j | i, i | j && j | i, i ^ j); return 0; }

Accepted Answer

Introduction / Context: This example tests detailed precedence and associativity across bitwise AND (&), XOR (^), OR (|), and logical AND (&&). Knowing that bitwise operators have higher precedence than logical && and that & binds more tightly than | is essential. Given Data / Assumptions: i = 4 (binary 0100), j = 8 (binary 1000). Precedence (high → low among these): & then ^ then | then &&. All bitwise operators associate left-to-right. Concept / Approach: Parse each expression with precedence rules, reduce bitwise operations to integers, then evaluate logical && which yields 0 or 1. Finally, print the results. Step-by-Step Solution: Expr1: i | j & j | i → i | (j & j) | i → 4 | 8 | 4 = 12.Expr2: i | j && j | i → (i | j) && (j | i) because | has higher precedence than && → (12) && (12) → 1.Expr3: i ^ j → 0100 ^ 1000 = 1100 → 12. Verification / Alternative check: Add parentheses explicitly to match the parsing above and re-run; you will see identical outputs: 12, 1, 12. Why Other Options Are Wrong: They assume different precedence (e.g., evaluating && earlier) or miscompute bitwise results. None match the correct parsing sequence defined by the C standard. Common Pitfalls: Believing logical && outranks bitwise |, or forgetting that nonzero integers are “true” for logical operators so 12 && 12 is 1, not 12. Final Answer: 12, 1, 12

Question 5

Bitwise OR, AND, and XOR with identical values in decimal and hex: compute and print all results.  #include<stdio.h>  int main() { int i = 32, j = 0x20; int k, l, m; k = i | j; l = i & j; m = k ^ l; printf("%d, %d, %d, %d, %d ", i, j, k, l, m); retu…

Accepted Answer

Introduction / Context: This problem reinforces equivalence between decimal and hexadecimal literals and the behavior of bitwise OR, AND, and XOR when both operands have exactly the same bit set. Here, 32 and 0x20 are the same value. Given Data / Assumptions: i = 32 and j = 0x20; both represent 0010 0000 in binary. k = i | j sets bits that are 1 in either operand. l = i & j sets bits that are 1 in both operands. m = k ^ l sets bits that differ between operands. Concept / Approach: When the operands are identical, OR and AND both equal the same value, while XOR becomes zero because there are no differing bits. Printing the five integers demonstrates this symmetry clearly. Step-by-Step Solution: Recognize i == j == 32.k = i | j = 32 | 32 = 32.l = i & j = 32 & 32 = 32.m = k ^ l = 32 ^ 32 = 0.printf prints: 32, 32, 32, 32, 0. Verification / Alternative check: Change j to 0x10 (16) and re-run to see different outcomes, emphasizing how XOR becomes nonzero when bits differ. Why Other Options Are Wrong: They imply mismatched values between decimal and hex, or misapply bitwise logic (e.g., XOR of equal values cannot be nonzero). Common Pitfalls: Assuming hex implies a different numeric value; forgetting binary representations; mixing up meanings of OR vs XOR. Final Answer: 32, 32, 32, 32, 0

Question 6

In C programming (assuming unsigned int is 2 bytes = 16 bits), what will this program print in hexadecimal?

#include<stdio.h>

int main()
{
 unsigned int a = 0xffff; // 16-bit all 1s
 ~a; // bitwise NOT result is not stored back
 printf("%x…

Accepted Answer

Introduction / Context: This question checks understanding of the bitwise NOT operator, expression side effects, and how assignment affects variables in C. It also relies on the assumption that unsigned int is 2 bytes (16 bits), so 0xffff represents all 1s in 16 bits. Given Data / Assumptions: unsigned int is 16 bits. a is initialized to 0xffff. The expression ~a is evaluated but its result is not assigned back to a. printf with %x prints a in lowercase hexadecimal without leading 0x. Concept / Approach: The operator ~ computes the bitwise complement of its operand, but unless the result is stored (e.g., a = ~a), the original variable is unchanged. Therefore the printed value is simply the original a. Step-by-Step Solution: Start: a = 0xffff.Compute ~a (result would be 0x0000 for 16-bit), but do not assign.a remains 0xffff.printf("%x", a) prints ffff. Verification / Alternative check: If the code were a = ~a; then a would become 0x0000 and the output would be 0000. Since there is no assignment, the output stays ffff. Why Other Options Are Wrong: 0000 / 00ff / ddfd: These assume the complement was stored or confuse the value. None applies here.None of the above: Incorrect because ffff is correct. Common Pitfalls: Assuming operators modify variables automatically; forgetting that expressions without assignment do not change stored values. Final Answer: ffff

Question 7

In C (unsigned int is 2 bytes = 16 bits), evaluate the effect of bitwise NOT on 32 and determine the printed hexadecimal value:

#include<stdio.h>

int main()
{
 unsigned int m = 32; // 0x0020 on 16 bits
 printf("%x
", ~m);
 return 0;
}
\…

Accepted Answer

Introduction / Context: This problem tests bitwise operations on fixed-width integers and hexadecimal formatting with printf. Assuming unsigned int is 16 bits, 32 decimal equals 0x0020 in hex. Given Data / Assumptions: unsigned int width: 16 bits. m = 32 → hex 0x0020. Bitwise NOT: ~x flips each bit within the integer width. printf("%x") prints lowercase hexadecimal, no 0x prefix. Concept / Approach: On 16 bits, ~0x0020 = 0xffdf because all bits invert: the bit 5 (value 0x0020) goes from 1 to 0 and the rest from 0 to 1, producing 1111 1111 1101 1111. Step-by-Step Solution: 32 = 0x0020 (binary 0000 0000 0010 0000).~0x0020 = 1111 1111 1101 1111 = 0xffdf.printf prints ffdf. Verification / Alternative check: Compute with the identity ~x = (2^n - 1) - x for n-bit unsigned: (2^16 - 1) - 0x0020 = 0xffff - 0x0020 = 0xffdf. Why Other Options Are Wrong: ffff: would be ~0, not ~32.0000 / ddfd: do not match the exact bitwise inversion. Common Pitfalls: Forgetting the assumed width; mixing signed and unsigned notions; misreading printf format. Final Answer: ffdf

Question 8

In C, consider missing arguments to printf: what will actually be printed (conceptually) by this code using bit shifts?

#include<stdio.h>

int main()
{
 printf("%d >> %d %d >> %d
", 4 >> 1, 8 >> 1);
 return 0;
}

Note: The format string …

Accepted Answer

Introduction / Context: This question assesses understanding of printf formatting and undefined behavior when the number of conversion specifiers does not match the number of provided arguments. It also includes simple right-shift operations 4 >> 1 and 8 >> 1. Given Data / Assumptions: Two arguments are supplied for four %d placeholders. 4 >> 1 equals 2; 8 >> 1 equals 4 for typical two’s complement integers. Accessing additional %d values with no corresponding arguments yields undefined behavior. Concept / Approach: printf reads arguments from the stack/variadic argument list according to the format string. Missing arguments mean printf will fetch whatever bits happen to be present, leading to unpredictable “garbage” values for the third and fourth %d. Step-by-Step Solution: First %d prints 4 >> 1 = 2.Literal text " >> " appears.Second %d prints 8 >> 1 = 4.Remaining two %d consume unspecified memory → unpredictable integers. Verification / Alternative check: If the call were corrected to printf("%d >> %d %d >> %d
", 4 >> 1, 1, 8 >> 1, 1), the output would be 2 >> 1 4 >> 1. As written, results beyond the first two are undefined. Why Other Options Are Wrong: Literal or fully defined outputs ignore the argument mismatch.“2 4” omits the format text and still ignores missing arguments. Common Pitfalls: Assuming printf quietly fills zeros; forgetting that varargs require a one-to-one match with conversion specifiers. Final Answer: 2 >> 4 Garbage value >> Garbage value

Question 9

Evaluate this macro-based C program: what integer does it print?

#define P printf("%d
", -1 ^ ~0)
#define M(P) int main()\n {\n P\n return 0;\n }
M(P)

Assume typical two’s-complement semantics.

Accepted Answer

Introduction / Context: The item tests bitwise reasoning with XOR and NOT, and macro expansion. Understanding two’s-complement behavior for ~0 and the identity x ^ x = 0 is key. Given Data / Assumptions: Expression: -1 ^ ~0. In two’s complement, ~0 is all 1 bits, which corresponds to -1 for signed int. printf prints a signed decimal integer. Concept / Approach: If two values have identical bit patterns, their XOR is zero: a ^ a = 0. Since -1 and ~0 are the same all-ones bit pattern, the result is 0. Step-by-Step Solution: Compute ~0 → all bits 1 → value equals -1 in two’s complement.Compute -1 ^ -1 → 0.printf prints 0. Verification / Alternative check: Try evaluating with fixed width (e.g., int32): ~0x00000000 = 0xffffffff; -1 is also 0xffffffff; XOR → 0x00000000. Why Other Options Are Wrong: 1, 2, -1: those would require differing bit patterns. Common Pitfalls: Confusing arithmetic negation with bitwise NOT; assuming ~0 is 0 (it is the opposite). Final Answer: 0

Question 10

Bit shifts with negative counts in C: determine the safest conclusion about this program’s outputs (assume typical hosted C, int is 32 bits).

#include<stdio.h>

int main()
{
 printf("%d %d
", 32<<1, 32<<0);
 printf("%d %d
", 32<<-1, 32<<-0…

Accepted Answer

Introduction / Context: This question gauges knowledge of defined vs. undefined behavior for bit shifts in C. While shifting by nonnegative counts is defined, any negative shift count leads to undefined behavior, meaning the program has no guaranteed result. Given Data / Assumptions: 32<<1 and 32<<0 are well-defined: 64 and 32. 32>>1 and 32>>0 are well-defined: 16 and 32. 32<<-1 and 32>>-1 have negative shift counts → undefined behavior. -0 is just 0, so shifts by -0 behave like 0 and are defined. Concept / Approach: Per the C standard, shifting by a negative count is undefined. Compilers may produce any result, crash, or optimize strangely. Therefore, any option claiming specific numeric values for those lines is unreliable; the safe, standard-aware answer is that outputs are indeterminate for the lines with negative counts. Step-by-Step Solution: Line 1: prints 64 32.Line 2: first shift is undefined; second is 32.Line 3: prints 16 32.Line 4: first shift is undefined; second is 32. Verification / Alternative check: Different compilers or optimization levels may show different numbers or traps for negative shifts, proving the behavior is not portable. Why Other Options Are Wrong: Any fully specified numeric sequence asserts a defined outcome for the negative shifts, which is not portable or guaranteed. Common Pitfalls: Assuming negative shifts “wrap” or always return 0; writing code that relies on compiler-specific extensions. Final Answer: Garbage values

Question 11

Assuming a 2-byte (16-bit) int in C, what hexadecimal value is printed here?

#include<stdio.h>

int main()
{
 printf("%x
", -1 << 3);
 return 0;
}

Pick the most appropriate result given typical two’s-complement behavior.

Accepted Answer

Introduction / Context: This tests bit-level reasoning and formatting with %x when left-shifting a negative value. Although left-shifting negative signed integers is technically undefined by the C standard, many exam contexts expect two’s-complement reasoning on 16-bit ints. Given Data / Assumptions: int is 16 bits. Two’s complement representation. -1 has all bits set: 0xffff. printf("%x") prints the underlying bit pattern in hexadecimal. Concept / Approach: Treating -1 as 0xffff, a left shift by 3 moves all 1s three positions left, filling the lowest three bits with zeros. That is 0xffff << 3 → 0xfff8 (if we ignore undefined-behavior concerns and assume wrap within 16-bit representation). Step-by-Step Solution: -1 (16-bit) = 0xffff.Shift left by 3: 0xffff << 3 = 0xfff8.Printed in hexadecimal → fff8. Verification / Alternative check: On implementations where int is 16-bit and two’s complement, compiling similar code often shows fff8. If int is wider or the compiler enforces UB strictly, results may vary; this exam assumes the common two’s-complement interpretation. Why Other Options Are Wrong: ffff: no shift would be required to get this.0 / -1: do not match the shifted bit pattern. Common Pitfalls: Forgetting exam assumptions; mixing signed arithmetic rules with bitwise representation in %x. Final Answer: fff8

Question 12

Given unsigned char i = 0x80 in C, what decimal value is printed?

#include<stdio.h>

int main()
{
 unsigned char i = 0x80; // 128
 printf("%d
", i << 1);
 return 0;
}

Assume usual integer promotions apply before the shift.

Accepted Answer

Introduction / Context: This item checks knowledge of the “usual integer promotions” and how bit shifts are performed in C when the operand is smaller than int. An unsigned char is promoted to int before shifting. Given Data / Assumptions: i = 0x80 (hex) = 128 (decimal). Left shift by 1 bit → multiply by 2 when no overflow in promoted type. printf uses %d, so it prints the decimal form of the resulting int. Concept / Approach: Before evaluating i << 1, i is promoted to int. Thus the operation is 128 << 1 as an int, yielding 256 without truncation during the operation. The result is then passed to printf and printed as a decimal integer. Step-by-Step Solution: unsigned char i = 128.Promote: (int)128 << 1 → 256.printf("%d") outputs 256. Verification / Alternative check: If you had stored the result back into an unsigned char (e.g., i = i << 1), it would wrap modulo 256 and become 0; but the code prints the promoted result directly. Why Other Options Are Wrong: 0: would occur only if storing back into 8 bits.100 / 80: unrelated decimal values. Common Pitfalls: Forgetting promotions; assuming 8-bit wrap happens during the shift expression itself. Final Answer: 256

Question 13

Concept check: In C, are the bitwise operators & and | unary operators or binary (dyadic) operators?

Accepted Answer

Introduction / Context: This conceptual question verifies operator arity in C. Understanding whether an operator is unary (one operand) or binary (two operands) is essential for parsing and writing expressions correctly. Given Data / Assumptions: Operators under consideration: & and |. We are discussing bitwise operators, not logical operators. Concept / Approach: In C, bitwise AND (&) and bitwise OR (|) each combine two operands bit-by-bit, producing a result of the same integer type after usual conversions. Therefore, they are binary (dyadic) operators. Their unary counterparts do not exist; the only unary bitwise operator is ~ (bitwise NOT). Step-by-Step Solution: Examine usage: a & b (two operands) and a | b (two operands).Contrast with unary operators such as ~a, +a, -a, ++a.Conclusion: & and | are binary. Verification / Alternative check: Refer to C operator precedence tables: & and | appear in binary operator groups (bitwise AND, bitwise OR), distinct from unary operator section. Why Other Options Are Wrong: True: incorrectly asserts that & and | are unary.Other distractors are irrelevant to the unary/binary distinction. Common Pitfalls: Confusing bitwise with logical operators (&&, ||), which are also binary, or mixing & (bitwise) with address-of operator & (unary) in a different context. Final Answer: False

Question 14

Reasoning about left shifts: Is left-shifting an integer by 1 always equivalent to multiplying it by 2 in C?
Answer considering overflow and signedness rules.

Accepted Answer

Introduction / Context: This concept check addresses the common heuristic that a left shift by 1 “multiplies by 2.” While often true for non-overflowing unsigned arithmetic, it is not universally valid in C because of overflow and signedness concerns. Given Data / Assumptions: C integer arithmetic can overflow. Signed overflow is undefined behavior. Unsigned arithmetic wraps modulo 2^n. Concept / Approach: For values where 2x fits in range and where the type is unsigned (or where behavior is defined), x << 1 equals x * 2. But if the shift discards significant bits (overflow) or if x is signed and the shift produces a negative or undefined state, the equivalence fails. Step-by-Step Solution: Consider unsigned 8-bit 200: 200 << 1 = 400 mod 256 = 144, not 400.Consider signed int near INT_MAX: shifting left by 1 can overflow → undefined behavior, not equal to 2x.Therefore, “always equivalent” is false. Verification / Alternative check: Compare x<<1 and x*2 across boundary cases in a small program for unsigned vs. signed types; you will observe differences at extremes. Why Other Options Are Wrong: True: ignores overflow and undefined behavior. Common Pitfalls: Overgeneralizing bit tricks; not distinguishing signed from unsigned; forgetting about modulo wrap for unsigned. Final Answer: False

Question 15

Bitwise AND for division: Can the bitwise & operator be used to divide an integer by powers of 2 in C?
Choose the correct statement.

Accepted Answer

Introduction / Context: This checks understanding of which bitwise operations correspond to division or modulo by powers of 2. Knowing the correct operator helps avoid bugs and write efficient low-level code. Given Data / Assumptions: We are operating on integers in C. Bitwise operators include & (AND) and | (OR); shift operators include << and >>. Concept / Approach: Division by 2^n is performed by right shifting (x >> n) for unsigned integers and implementation-defined for signed with arithmetic right shift. Bitwise AND with a mask (x & (2^n - 1)) computes x modulo 2^n, not division. Step-by-Step Solution: To divide x by 4 (2^2), use x >> 2 (for unsigned x).Using x & 3 yields x mod 4, i.e., the remainder, not the quotient.Therefore, saying bitwise & can be used to divide is false. Verification / Alternative check: Test with x = 13: 13 >> 2 = 3 (division), while 13 & 3 = 1 (remainder). Clearly different. Why Other Options Are Wrong: True: confuses modulo with division. Common Pitfalls: Using the wrong operation for quotient vs. remainder; assuming bitwise tricks all do the same task. Final Answer: False

Question 16

In C/C++, can the bitwise AND operator (&) be used to test whether more than one bit is set in an integer?

Give a precise, programming-focused answer and consider common idioms such as x & (x - 1) to detect if multiple bits are on.

Accepted Answer

Introduction / Context: This question assesses your understanding of bitwise operations in C/C++ and, specifically, the ability to test whether an integer value has more than one bit set. Knowing these idioms is essential for low-level programming, embedded work, interview questions, and performance-sensitive code such as bitmap or mask handling. Given Data / Assumptions: You are working with typical two’s-complement integers. Bitwise operators work on the underlying bit patterns of the integer. No undefined behavior is introduced by the shown expressions when applied to ordinary signed or unsigned ints (excluding extreme corner cases like INT_MIN with certain arithmetic if you subtract). Concept / Approach: A classic technique to determine whether an integer x has more than one bit set uses the expression x & (x - 1). The idea relies on the fact that subtracting 1 from a value flips the lowest set bit to 0 and turns all lower bits to 1; AND-ing with the original value removes that lowest set bit. If the result is nonzero, at least one additional set bit existed beyond the least significant one. To detect “two or more bits set,” we check if (x & (x - 1)) != 0. To check exactly one bit set, test x != 0 && (x & (x - 1)) == 0. Step-by-Step Solution: Let x be an integer mask.Compute y = x & (x - 1).If y != 0, then x had more than one bit set; if y == 0 and x != 0, then exactly one bit was set; if x == 0, then no bits were set. Verification / Alternative check: Try x = 8 (binary 1000). Then x & (x - 1) = 1000 & 0111 = 0000 (exactly one bit set). For x = 10 (1010), x & (x - 1) = 1010 & 1001 = 1000 (nonzero → more than one bit set). Why Other Options Are Wrong: Incorrect: Proven standard idiom exists.Only for unsigned integers; never for signed: The bit trick works equally well for signed magnitudes as long as arithmetic does not overflow, because it operates on bit patterns.Not possible without division or modulo: Division is unnecessary.Applies only on little-endian machines: Endianness does not affect bitwise arithmetic. Common Pitfalls: Forgetting to treat x == 0 as a special case; confusing the test for “exactly one bit set” with the test for “two or more bits set.” Final Answer: Correct.

Question 17

Right shifting a negative (signed) integer: does the result vary across systems when using expression1 >> expression2 if the sign bit is 1?

Accepted Answer

Introduction / Context: This question probes your knowledge of how the right-shift operator works on signed integers. Unlike unsigned right shifts, which are unambiguous, right shifts of negative signed integers can differ by platform because of how the sign bit is treated (arithmetic vs logical shift). Given Data / Assumptions: expression1 is a signed integer with the most significant bit set (a negative number in two’s complement). expression2 is a nonnegative shift count. We are discussing standard C/C++ behavior across different compilers and architectures. Concept / Approach: For unsigned types, right shift inserts zeros on the left (logical shift). For signed types, the C and C++ standards permit implementation-defined behavior: compilers may perform an arithmetic shift (propagating the sign bit, keeping the value close to division by 2 rounding toward negative infinity) or a logical shift (inserting zeros). Most two’s-complement compilers choose arithmetic shift, but the language does not require it. Thus, results may vary across compilers and systems. Step-by-Step Solution: Take x = -8 (binary …11111000 in two’s complement).Right shift by 1: arithmetic shift may yield …11111100 (which is -4), while logical shift would yield …01111100 (a large positive number if interpreted as signed bits).Since the standard allows implementation-defined choices, outcomes can differ across platforms. Verification / Alternative check: Consult your compiler’s documentation or test with a small program to see whether -8 >> 1 yields -4 (arithmetic) or something else (logical). Why Other Options Are Wrong: “Incorrect — the C standard mandates logical/arithmetic shift”: No, it does not mandate one fixed behavior for signed right shifts.“Undefined behavior”: It is implementation-defined, not undefined.“Always equals division by 2”: Only if arithmetic shift is used and rounding rules align; not guaranteed. Common Pitfalls: Assuming all compilers use arithmetic shift; writing portable code that depends on a specific signed shift behavior. Final Answer: Correct — it is implementation-defined and may differ by compiler or CPU.

Question 18

Using bitwise AND (&) with a mask to test whether a specific bit is set in an integer: is this a valid and standard technique?

Accepted Answer

Introduction / Context: Testing individual bits is a foundational skill in systems programming, device drivers, embedded development, and competitive programming. The classic approach is to use the bitwise AND operator with a mask that has the target bit set to 1 and all other bits 0. Given Data / Assumptions: x is an integer value. mask is an integer with a 1 in the bit position we want to test and 0 elsewhere (e.g., 1u << k). We want a boolean-like result indicating whether the bit is set. Concept / Approach: The expression (x & mask) != 0 evaluates to true if and only if the corresponding bit in x is 1. This works because AND preserves a 1 only where both operands have a 1. It is completely independent of endianness, as endianness affects byte ordering in memory, not the logical interpretation of bit positions within an arithmetic expression. Step-by-Step Solution: Construct mask = 1u << k to target bit k.Compute test = x & mask.If test != 0, the kth bit is set; otherwise it is clear. Verification / Alternative check: For x = 10 (1010b) and k = 1, mask = 0010b; x & mask = 0010b != 0 → bit 1 is set. For k = 0, mask = 0001b; x & mask = 0000b → bit 0 is not set. Why Other Options Are Wrong: Incorrect: This is a standard technique.Valid only for powers-of-two masks: Any mask that isolates desired bits works; a single-bit mask is indeed a power of two, but the approach is general.Endianness: Not relevant to bitwise evaluation.Requires multiplication/division: Unnecessary; bitwise AND is sufficient. Common Pitfalls: Using signed shifts incorrectly; forgetting to use unsigned types when shifting to build masks. Final Answer: Correct.

Question 19

Is left shifting an unsigned int or unsigned char by 1 always equivalent to multiplying by 2 (in practical C/C++ code)?

Accepted Answer

Introduction / Context: Programmers often say “left shift by 1 multiplies by 2.” While this is commonly true, the always in the statement can be misleading. Understanding when the equivalence holds and when it breaks is crucial for writing correct, portable bit-level code in C/C++. Given Data / Assumptions: We are dealing with unsigned integers (e.g., unsigned int or unsigned char). Left shift operator «<<» and multiplication by 2 are compared. The machine uses fixed-width unsigned types (e.g., 8, 16, 32 bits). Concept / Approach: For unsigned types, left shift by k mathematically corresponds to multiplication by 2^k modulo 2^N, where N is the bit width. If the mathematical product stays within the representable range (no high bits lost), the operations agree. However, when the product requires more than N bits, left shift discards the overflowing bits, effectively wrapping modulo 2^N. Saying “always equivalent” ignores this overflow/wrap aspect. In contrast, the phrase “multiply by 2” usually implies mathematical integer multiplication without wraparound. Step-by-Step Solution: Let N = 8, x = 200. x << 1 = 144 (since 200 * 2 = 400, and 400 mod 256 = 144).Mathematically, 200 * 2 = 400; this cannot be represented in 8 bits. The left shift wrapped, so it is not equivalent to the mathematical product.If x = 60, x << 1 = 120, which matches 60 * 2, since no overflow occurs. Verification / Alternative check: Use wider types (e.g., unsigned long long) to see when overflow occurs. If you need guaranteed mathematical multiplication, promote to a wider type before shifting or multiplying. Why Other Options Are Wrong: “Correct — for all values”: ignores wrap.Endianness is irrelevant to arithmetic equivalence.“Only if the value is odd”: parity does not govern overflow here.“Equivalent only for signed integers”: signed left-shift has additional rules and potential undefined behavior on overflow. Common Pitfalls: Assuming left shift is a safe substitute for multiplication in all cases; overlooking overflow and silent wrap behavior. Final Answer: Incorrect — it fails when the result would overflow the type width.

Question 20

When you left shift an integer in C/C++, do the leftmost bits “rotate” around to the right side (i.e., is a left shift a rotate)?

Accepted Answer

Introduction / Context: This concept distinguishes between shift and rotate operations. Many beginners mistakenly believe that shifting “wraps” bits around. In C/C++, the standard shift operators «<<» and »>>« are shifts, not rotates. Rotates require special intrinsics, inline assembly, or explicit code to simulate wrapping behavior. Given Data / Assumptions: We are using the built-in shift operators. No compiler-specific rotate intrinsics are being invoked. We are not discussing circular buffers or logical constructs; this is bit-level operation. Concept / Approach: Left shift moves bits toward more significant positions. The vacated rightmost positions are filled with zeros. Bits that move past the most significant position are discarded. There is no implicit rotation. Right shift works similarly but toward less significant positions; for unsigned types, zeros enter on the left; for signed types, left-fill may be zeros or sign bits, depending on implementation. Step-by-Step Solution: Consider an 8-bit value 10110001 (0xB1). Left shift by 2 yields 11000100 (0xC4). The two leftmost bits (10) that “fell off” are lost, not wrapped to the right.To rotate, you would need something like: (x << k) | (x >> (N - k)) with proper masking, or use compiler intrinsics if available. Verification / Alternative check: Try examples in a small C program; you will never see wrap with standard shift operators unless you explicitly code it with ORs and masks. Why Other Options Are Wrong: “Correct — bits rotate”: False for standard shift operators.Endianness, type width, or optimization level do not change semantics of shift into rotate. Common Pitfalls: Confusing rotate with shift; assuming hardware CPU rotate instructions are automatically used by the compiler for «<<» or »>>« semantics (they are not). Final Answer: Incorrect — ordinary shifts do not rotate; they discard shifted-out bits.

Bitwise Operators Questions