Q: Spot the effect of a stray semicolon after a for loop in C. What does this program print? #include int main() { int i = 0; for (; i <= 5; i++); printf("%d", i); return 0; }

Introduction / Context: This exercise highlights a common bug: placing a semicolon immediately after a for loop header. That semicolon makes the loop body empty, and the following statement executes once, after the loop finishes. Given Data / Assumptions: Loop header: for (; i <= 5; i++); has an empty body. After the loop, a single printf prints the current value of i. Concept / Approach: The loop increments i from 0 up to 6, stopping when the condition i <= 5 becomes false. The moment the loop terminates, i holds 6. Then, and only then, the printf executes once and prints the final value of i with no newline. Step-by-Step Solution: Start: i = 0.Loop runs with empty body while i = 0,1,2,3,4,5.Next increment makes i = 6; condition fails; exit loop.Execute printf("%d", i); → prints 6. Verification / Alternative check: Add braces to make the intended body explicit or remove the stray semicolon to iterate printing multiple numbers. Why Other Options Are Wrong: Sequences like 0..5 would occur only if the printf were inside the loop body (it is not).5 is not printed; i advances beyond 5 before termination.Compilation error: syntax is legal. Common Pitfalls: Misplacing semicolons after loop headers; forgetting braces for multi-statement bodies. Final Answer: 6.

Question 1

C#.NET — Control flow semantics: switch, goto/continue, jump statements, and do loops. Which statements are correct?

Accepted Answer

Introduction / Context: This conceptual item asks you to pick the accurate descriptions of several C# control-flow constructs: switch, jump statements (break/continue/goto/return), and the do loop. The distractors intentionally conflate goto and continue behaviors with switch case labels. Given Data / Assumptions: Five statements cover switch, goto, jump semantics, continue, and do. Concept / Approach: Recall: switch selects among cases; jump statements cause immediate transfers of control; continue skips to the next iteration of the current loop, not to a switch label; the do statement executes the body at least once, then repeats until the expression becomes false. Step-by-Step Solution: 1) Correct — switch handles multiple selections via case labels (and can be used with enums). 2) Incorrect — goto does not inherently “go to next iteration”; that is continue. Plain goto transfers to a label. 3) Correct — break/continue/goto/return are jump statements that transfer control immediately. 4) Incorrect — continue does not target switch labels; use goto case/goto default within switch. 5) Correct — do { ... } while (expr); repeats until expr evaluates to false. Verification / Alternative check: Write micro-examples using each construct and observe the control flow in a debugger; the behaviors align with the reasoning above. Why Other Options Are Wrong: A/C/D include false statements 2 or 4, so they cannot be correct. Common Pitfalls: Assuming continue can send control into arbitrary labels or switch cases; misunderstanding that do executes once before the first test. Final Answer: 1, 3, 5

Question 2

Evaluate short-circuit and precedence for logical operators in C. What is printed?  #include<stdio.h> int main() {  int x, y, z;  x = y = z = 1;  z = ++x || ++y && ++z;  printf("x=%d, y=%d, z=%d ", x, y, z);  return 0; }  Assume standard operator pr…

Accepted Answer

Introduction / Context: This classic interview problem tests knowledge of operator precedence and short-circuiting with side effects from pre-increment operators. Given Data / Assumptions: Initial values: x = y = z = 1. Expression: z = ++x || ++y && ++z. Precedence: ++ (unary) > && > ||. Short-circuit behavior: if the left of || is nonzero, the right side is not evaluated. Concept / Approach: First evaluate ++x, then evaluate the || with the right-hand side (which itself contains &&) only if needed. Because ++x makes x nonzero (2), the left of || is true and the rest is skipped. Step-by-Step Solution: Compute ++x → x becomes 2 → nonzero → left operand of || is true.Since left of || is true, the right-hand expression (++y && ++z) is not evaluated.The value of the overall expression is 1 (true), so z is assigned 1.Final values: x = 2, y = 1, z = 1. Verification / Alternative check: Parenthesize explicitly as z = (++x) || ((++y) && (++z)); and manually simulate short-circuiting to reach the same result. Why Other Options Are Wrong: x=2, y=2, z=1 or z=2: would require evaluating ++y or ++z, which does not occur.x=1, y=2, z=1: contradicts ++x being evaluated first. Common Pitfalls: Misremembering precedence between && and ||; forgetting that short-circuiting stops evaluation of the rest of the expression. Final Answer: x=2, y=1, z=1

Question 3

In C programming, what will be the output of the following program?  #include<stdio.h> int main() { char ch; if (ch = printf("")) printf("It matters "); else printf("It doesn't matters "); return 0; }

Accepted Answer

Introduction / Context: This C output question tests your understanding of what printf returns and how assignment within an if condition behaves. Many beginners assume that an empty printf “does nothing,” but overlooking its return value leads to incorrect conclusions about the executed branch. Given Data / Assumptions: The program compiles with a standard C compiler. printf returns the number of characters printed. The expression (ch = printf("")) assigns the return value of printf to ch and uses that value as the condition. Concept / Approach: printf returns an int equal to the count of characters written. When given an empty string literal "", it prints zero characters and therefore returns 0. The if statement evaluates the assigned value as a boolean: 0 means false; any nonzero value means true. Because 0 is false, the else block will execute. Step-by-Step Solution: Call: printf("") → prints nothing → returns 0.Assignment: ch = 0.Condition: if (0) is false → execute the else branch.Output line: It doesn't matters followed by a newline. Verification / Alternative check: Add a diagnostic: printf("ret=%d", printf("")); It will first print nothing, then print ret=0, confirming the return value of zero for the empty string. Why Other Options Are Wrong: It matters: would require a nonzero return from printf, which is not the case for "".matters: not printed anywhere in code.No output: the else branch prints a line.Compilation error: all syntax is valid C. Common Pitfalls: Confusing assignment = with equality ==; assuming printf with an empty string returns nonzero; forgetting that the value assigned is exactly what the if tests. Final Answer: It doesn't matters.

Question 4

In C (16-bit short int), what will this program print? Assume a short int is 2 bytes. #include int main() { short int i = 0; for (i <= 5 && i >= -1; ++i; i > 0) printf("%u,", i); return 0; }

Accepted Answer

Introduction / Context: This problem checks your grasp of the three for clauses in C and how they are evaluated, as well as 16-bit integer overflow behavior. The code uses expressions in unexpected clauses and prints with the %u specifier, which adds to the challenge. Given Data / Assumptions: short int is 16 bits (range −32768 to 32767). %u prints as unsigned (the argument is int after promotion; although the format is mismatched, typical implementations still display a value). for (init; condition; increment) executes init then condition then body then increment repeatedly. Concept / Approach: In this loop, the “init” is the boolean expression i <= 5 && i >= -1 which is evaluated and discarded. The “condition” is ++i, so each iteration starts by incrementing i and testing nonzero. The “increment” is the expression i > 0, which is evaluated and discarded. Thus i climbs from 0 to 1, 2, …; when it passes 32767, it overflows to −32768 and continues up to −1, and the next ++i becomes 0, ending the loop. The printing happens once per iteration. Step-by-Step Solution: Start: i = 0.Condition: ++i → 1 (true) → prints 1,.Iterate: i runs across all remaining 16-bit values until ++i yields 0 after wrapping from −1 to 0.Net effect: the program prints values equivalent to 1 through 65535 when viewed as unsigned. Verification / Alternative check: Replace %u by %d to see the signed sequence (1, 2, …, 32767, −32768, …, −1). With %u, the negative half renders as 32768…65535, yielding the full 1…65535 run. Why Other Options Are Wrong: Expression syntax error: The for clauses are legal expressions.No output or 0..5: contradicted by the loop behavior and wraparound.Infinite loop with no printing: the loop terminates when ++i becomes 0. Common Pitfalls: Misinterpreting the role of the three for clauses; expecting the initial clause to assign; overlooking integer overflow wrap in two’s complement. Final Answer: 1 ... 65535.

Question 5

C (16-bit unsigned int assumed): what does this program print?  #include<stdio.h> int main() { unsigned int i = 65536; /* Assume 2 byte integer */ while (i != 0) printf("%d", ++i); printf(" "); return 0; }

Accepted Answer

Introduction / Context: This question targets integer width assumptions and initialization effects. Assigning a value outside the range of a 16-bit unsigned type causes wraparound, which directly determines whether the loop body executes at all. Given Data / Assumptions: unsigned int is assumed to be 16 bits (0..65535). 65536 is exactly 2^16, so it wraps to 0 on assignment in a 16-bit unsigned int. The while loop executes only if i != 0. Concept / Approach: On a 16-bit model, unsigned int i = 65536; stores 0 because 65536 mod 65536 = 0. Therefore the loop condition (i != 0) is false at the first test, and the loop body is skipped entirely. Only the trailing newline is printed, which most judges interpret as “no visible output.” Step-by-Step Solution: Assignment: i becomes 0 after wrap.Condition: i != 0 → false → loop not entered.Program prints only "". Verification / Alternative check: Change the initializer to 65535 and observe the loop execute; or print the value of i immediately after initialization to confirm it is 0. Why Other Options Are Wrong: Infinite loop / sequences of numbers: require the loop to start; here it never starts.Compilation error: standard-compliant code. Common Pitfalls: Forgetting the target width of unsigned int on 16-bit assumptions; assuming 32-bit widths everywhere. Final Answer: No output.

Question 6

Evaluate the output of this C program that uses logical negation:  #include<stdio.h> int main() { int x = 10, y = 20; if (!(!x) && x) printf("x = %d ", x); else printf("y = %d ", y); return 0; }

Accepted Answer

Introduction / Context: This item checks how logical negation interacts with nonzero integers in C. Any nonzero value is considered true. Applying ! flips truthiness, not the numeric magnitude (except reducing truthy to 0 and false to 1). Given Data / Assumptions: x = 10 (nonzero → true), y = 20. Expression: !(!x) && x. Short-circuit semantics of && apply. Concept / Approach: !x converts any nonzero to 0 and zero to 1. Thus !x becomes 0, and !(!x) becomes 1. The second operand of && is x (which is nonzero). Therefore, 1 && 10 is true, so the if branch executes, printing the current numeric value of x (10). Step-by-Step Solution: !x → 0 because x is nonzero.!(!x) → 1.1 && x → true because x is nonzero.Print: x = 10. Verification / Alternative check: Replace x by 0 and re-run to see the else branch. Replace x by −5 and note that it is still treated as true. Why Other Options Are Wrong: y = 20: would print only if the condition were false.x = 0 / x = 1: the program prints the actual stored value (10), not a truthy/falsey normalized value.No output: one branch must print. Common Pitfalls: Confusing logical truthiness with numeric value; assuming !10 creates −10 (it does not). Final Answer: x = 10.

Question 7

On a 16-bit unsigned int, determine the behavior of this loop (does it terminate, and what does it print)? #include int main() { unsigned int i = 65535; /* Assume 2 byte integer */ while (i++ != 0) printf("%d", ++i); printf(" "); …

Accepted Answer

Introduction / Context: This problem explores subtle interactions among post-increment in a loop condition, pre-increment in the body, and modulo arithmetic on a 16-bit unsigned int. Understanding the net change per iteration reveals whether the loop can ever reach the sentinel value 0 in its condition. Given Data / Assumptions: unsigned int is 16 bits (0..65535). Condition uses i++ (post-increment). Body uses ++i (pre-increment). Arithmetic wraps modulo 65536. Concept / Approach: At the first test, i++ yields 65535 (nonzero) and then wraps i to 0. The body runs and ++i sets i to 1 and prints it. Thereafter, each iteration adds 1 in the condition and 1 in the body, for a net increase of 2 per full cycle. Starting from 1 (odd), repeatedly adding 2 cycles through all odd residues modulo 65536. Because 0 is even, the value tested in the next condition (the pre-incremented state from the previous step, then post-incremented) will never be 0 at the moment of comparison. Hence, the loop never terminates. Step-by-Step Solution: Initial: i = 65535.Condition: test 65535 → true; i becomes 0.Body: ++i → 1 printed.Next iterations: i advances by +2 overall; it never equals 0 at the instant of comparison. Verification / Alternative check: Instrument the code: print i at the top of each loop to observe the odd sequence 1, 3, 5, … wrapping but never hitting 0. Why Other Options Are Wrong: Finite sequences require the comparison to become false; it never does.“No output” is impossible because the first iteration certainly prints. Common Pitfalls: Overlooking the combined effects of post-increment in the condition and pre-increment in the body; ignoring modulus-wrap properties. Final Answer: Infinite loop.

Question 8

Floating-point comparison in C: given float a = 0.7;, what will this program print and why? #include int main() { float a = 0.7; if (0.7 > a) printf("Hi "); else printf("Hello "); return 0; }

Accepted Answer

Introduction / Context: This question examines a classic floating-point pitfall: comparing a float against a double literal. Because decimal fractions rarely have exact binary representations, the comparison may not behave as naive intuition suggests. Given Data / Assumptions: a is a float, typically ~7 decimal digits precision. 0.7 is a double literal, typically ~15–16 digits precision. In the comparison, a is promoted to double for evaluation. Concept / Approach: The binary representation of 0.7 cannot be exact. When you write float a = 0.7;, the value stored in a is the nearest representable float to 0.7, which is usually slightly less than the double literal 0.7. During comparison, a is promoted to double, preserving its slightly smaller value. Therefore, 0.7 > a typically evaluates to true, and the program prints Hi. Step-by-Step Solution: Store: a gets a rounded float approximation of 0.7.Promote: a → double for comparison.Compare: 0.7 (double) is slightly larger than promoted a → condition true.Output: Hi. Verification / Alternative check: Print with high precision: printf("%.20f %.20f", 0.7, (double)a); You will see the promoted a is marginally smaller than the literal. Why Other Options Are Wrong: Hello: would require 0.7 <= a, which is not typical.Multiple or no outputs: the code prints exactly one line. Common Pitfalls: Assuming decimal equality in binary floating-point; mixing float and double without awareness. Final Answer: Hi.

Question 9

Spot the effect of a stray semicolon after a for loop in C. What does this program print? #include int main() { int i = 0; for (; i <= 5; i++); printf("%d", i); return 0; }

Accepted Answer

Introduction / Context: This exercise highlights a common bug: placing a semicolon immediately after a for loop header. That semicolon makes the loop body empty, and the following statement executes once, after the loop finishes. Given Data / Assumptions: Loop header: for (; i <= 5; i++); has an empty body. After the loop, a single printf prints the current value of i. Concept / Approach: The loop increments i from 0 up to 6, stopping when the condition i <= 5 becomes false. The moment the loop terminates, i holds 6. Then, and only then, the printf executes once and prints the final value of i with no newline. Step-by-Step Solution: Start: i = 0.Loop runs with empty body while i = 0,1,2,3,4,5.Next increment makes i = 6; condition fails; exit loop.Execute printf("%d", i); → prints 6. Verification / Alternative check: Add braces to make the intended body explicit or remove the stray semicolon to iterate printing multiple numbers. Why Other Options Are Wrong: Sequences like 0..5 would occur only if the printf were inside the loop body (it is not).5 is not printed; i advances beyond 5 before termination.Compilation error: syntax is legal. Common Pitfalls: Misplacing semicolons after loop headers; forgetting braces for multi-statement bodies. Final Answer: 6.

Question 10

Trace the output for the following C program with post-decrement in the condition and multiple loops:  #include<stdio.h> int main() { int i = 5; while (i-- >= 0) printf("%d,", i); i = 5; printf(" "); while (i-- >= 0) printf("%i,", i); while (i-- >= …

Accepted Answer

Introduction / Context: This problem focuses on how i-- behaves in a loop condition and how the variable's value changes before the body executes. It also contrasts two loops separated by a reset and a newline, then shows that a final loop may not execute at all. Given Data / Assumptions: Initial i = 5. Condition i-- >= 0 compares first, then decrements. The body prints the current (already decremented) i. Concept / Approach: When the condition is i-- >= 0, the comparison uses the old value of i, then i is decremented before entering the body. Consequently, the printed sequence is one less than the value checked in the condition. The loop runs while the old value is at least 0, producing a sequence down to −1 in the output. Step-by-Step Solution: First loop: start i = 5 → check 5 >= 0 → decrement to 4 → print 4; then 4→3, 3→2, 2→1, 1→0, 0→−1 (printing −1), then stop.Reset i = 5; print newline.Second loop repeats the same logic with %i (same as %d) producing 4, 3, 2, 1, 0, -1.Third loop: after the second loop, i is −1; condition i-- >= 0 is false at once; no output. Verification / Alternative check: Change the condition to --i >= 0 or i >= 0 with a separate decrement to see how the printed values shift. Why Other Options Are Wrong: Sequences starting from 5 reflect --i in the body or a different condition; not the case here.Error/No output: the program is valid and clearly prints two sequences. Common Pitfalls: Forgetting the difference between pre- and post-decrement; assuming %i and %d differ for int (they do not). Final Answer: 4, 3, 2, 1, 0, -1 4, 3, 2, 1, 0, -1.

Question 11

What is the output of this switch statement in C? Note the statement before any case label. #include int main() { int i = 1; switch (i) { printf("Hello "); case 1: printf("Hi "); break; case 2: printf("Bye "); bre…

Accepted Answer

Introduction / Context: This question checks knowledge of switch control flow. Statements inside a switch that precede any case label are not “default prelude” statements; control transfers directly to the matching case label, skipping earlier statements. Given Data / Assumptions: i = 1. There is a printf("Hello"); placed before the case labels. Standard C switch semantics apply: jump to the matching label and execute from there. Concept / Approach: When switch (i) is executed, the implementation looks for a matching case label (here case 1) and transfers control directly to that label. No statement before that label will run. Therefore, only the statements under case 1 (up to the break) execute. Step-by-Step Solution: Evaluate switch (1) → jump to case 1.Execute: printf("Hi");.Encounter break → exit the switch. Verification / Alternative check: Move printf("Hello"); after case 1: and before the printf("Hi");. Then both lines will print; this confirms the role of label placement. Why Other Options Are Wrong: Options including “Hello” assume the pre-label statement executes; it does not.“Bye” corresponds to case 2, which does not match.“No output” contradicts the executed printf in case 1. Common Pitfalls: Assuming topmost statements run before label dispatch; forgetting that code before the first case is dead unless jumped to. Final Answer: Hi.

Question 12

Evaluate the conditional (ternary) operator: what does this program print?  #include<stdio.h> int main() { int k, num = 30; k = (num < 10) ? 100 : 200; printf("%d ", num); return 0; }

Accepted Answer

Introduction / Context: This item clarifies that the ternary operator result is stored in k, but the program prints the original variable num. It tests whether you are reading carefully rather than assuming the printed value equals the conditional result. Given Data / Assumptions: num = 30. Ternary expression: (num < 10) ? 100 : 200. Print statement: printf("%d", num); prints num, not k. Concept / Approach: Since num is 30, the condition num < 10 is false, so the expression yields 200 and assigns it to k. However, the program never prints k; it prints num, which remains unchanged at 30. Therefore, the output is 30 regardless of the value assigned to k. Step-by-Step Solution: Compute ternary: false → choose 200 → k = 200.No modification to num occurs.Print num → 30. Verification / Alternative check: Change the final line to printf("%d", k); to see 200 printed; or set num = 5 to observe k become 100 while num remains 5. Why Other Options Are Wrong: 200/100: those are values assigned to k, not printed.500: not produced by any expression.Compilation error: the code is valid. Common Pitfalls: Assuming the printed variable is the same one assigned by the conditional expression; not tracking which identifier is passed to printf. Final Answer: 30.

Question 13

In C programming, evaluate the conditional operator used with lvalues (addresses): what is the output?  #include<stdio.h> int main() {  int a=0, b=1, c=3;  ((a)? &b : &a) = a? b : c;  printf("%d, %d, %d ", a, b, c);  return 0; }

Accepted Answer

Introduction / Context: This C question tests deep understanding of the conditional (ternary) operator when used with lvalues (addresses) and ordinary values. It also checks evaluation order and how pointers produced by the operator can be dereferenced to assign into a selected variable. Given Data / Assumptions: a = 0, b = 1, c = 3 at program start. The expression uses both a conditional that yields an address and a conditional that yields a value. printf prints a, b, c in that order. Concept / Approach: The conditional operator has the form cond ? expr1 : expr2. If cond is nonzero (true), expr1 is evaluated and chosen; otherwise expr2 is chosen. When both expr1 and expr2 are pointers to the same effective type, the result is a pointer (an lvalue context can be created by dereferencing). Here the left-hand side is ((a) ? &b : &a), which chooses an address to write to; the right-hand side is a ? b : c, which chooses a numeric value to assign. Step-by-Step Solution: Evaluate condition a: a == 0 → false.Left-hand side picks &a (because a is false). Thus LHS is *(&a) which aliases variable a.Right-hand side a ? b : c → since a is false, choose c → value 3.Assignment executes: a = 3. Variables now: a=3, b=1, c=3.printf prints: 3, 1, 3. Verification / Alternative check: Replace a with 1 initially and mentally re-run: LHS would choose &b and RHS would choose b, assigning b=b (no change). This contrast confirms the logic. Why Other Options Are Wrong: “0, 1, 3” assumes no assignment happened. “1, 2, 3” or “1, 3, 1” have unjustified changes to variables b or c. Common Pitfalls: Forgetting that the ternary can return an lvalue-compatible pointer; mixing up which branch is selected; assuming both branches evaluate (they do not). Final Answer: 3, 1, 3

Question 14

In C, how does == behave when comparing an int and a float with equal numeric value?  #include<stdio.h> int main() {  int x = 3;  float y = 3.0;  if(x == y)  printf("x and y are equal");  else  printf("x and y are not equal");  return 0; }

Accepted Answer

Introduction / Context: This item checks the rules of the usual arithmetic conversions in C when comparing different types (int and float). It probes whether the integer is converted to a floating point value before the comparison. Given Data / Assumptions: x is 3 (type int) and y is 3.0 (type float). The program uses == to compare them and prints a message accordingly. Concept / Approach: For the relational and equality operators, C applies the usual arithmetic conversions so both operands share a common type. With int and float, the int is converted to float. Therefore comparison becomes 3.0f == 3.0f which is true. Step-by-Step Solution: Convert x to float: (float)3 → 3.0f.Compare 3.0f == 3.0f → true.The if branch executes and prints “x and y are equal”. Verification / Alternative check: Changing y to 3.0000001f would likely make the comparison false after conversion. As written, exact equality holds with small integers representable exactly in float. Why Other Options Are Wrong: “Not equal” contradicts conversion rules. “Unpredictable/No output/Compilation error” are not applicable. Common Pitfalls: Believing that int and float are never equal; confusing floating-point rounding issues with integers exactly representable in float (all integers up to 2^24 are exactly representable in IEEE 754 single precision). Final Answer: x and y are equal

Question 15

C switch fall-through with a default label before cases: determine program output  #include<stdio.h> int main() {  int i=4;  switch(i)  {  default:  printf("This is default ");  case 1:  printf("This is case 1 ");  break;  case 2:  printf("This is c…

Accepted Answer

Introduction / Context: This problem examines how a switch statement behaves when the switch expression does not match any case label, but there is a default label placed before other cases. It also checks understanding of fall-through and the effect of break. Given Data / Assumptions: i equals 4; there is no case 4. The default label appears before case 1 and is not followed by a break. case 1 has a break; subsequent cases also contain breaks or end. Concept / Approach: If no case matches, control jumps to default. Execution then continues sequentially until a break or the end of the switch. Because default is followed by case 1 without a break, the code “falls through” into case 1 and prints both lines. Step-by-Step Solution: No case 4: jump to default.Execute printf → “This is default”.Fall through to case 1 → print “This is case 1”.Hit break at case 1 → exit switch. No other lines print. Verification / Alternative check: Insert a break after default and re-run: only “This is default” would print. This demonstrates fall-through behavior. Why Other Options Are Wrong: Other orders do not reflect control flow: case 3 never runs; printing only default ignores fall-through. Common Pitfalls: Assuming default must appear last; forgetting that missing break allows fall-through; expecting an implicit break after default. Final Answer: This is default This is case 1

Question 16

Operator precedence with logical NOT (!) and relational >= : evaluate the output  #include<stdio.h> int main() {  int a = 500, b = 100, c;  if(!a >= 400)  b = 300;  c = 200;  printf("b = %d c = %d ", b, c);  return 0; }

Accepted Answer

Introduction / Context: This question probes operator precedence and associativity between logical NOT (!) and relational operators (>=). It tests whether you know that unary ! is applied before the comparison. Given Data / Assumptions: a = 500, b = 100 initially. c is assigned 200 unconditionally after the if. Prints b and c. Concept / Approach: In C, unary operators like ! have higher precedence than relational operators like >=. Therefore the expression is parsed as (!a) >= 400, not as !(a >= 400). Since a is 500 (nonzero), !a is 0. Then 0 >= 400 is false, so the body of the if does not execute. Step-by-Step Solution: Compute !a: !500 → 0.Compare 0 >= 400 → false.Therefore b remains 100.c is set to 200.printf prints “b = 100 c = 200”. Verification / Alternative check: Parenthesize as !(a >= 400) (which evaluates to false) to see explicitly the same result. Change a to 0 to test the true branch: !0 is 1, and 1 >= 400 is false; still no assignment to b. Why Other Options Are Wrong: Claims that b becomes 300 ignore precedence; “garbage” for c is invalid because c is definitely assigned before printing. Common Pitfalls: Misreading the expression as !(a >= 400); overlooking that !a yields 0 or 1 only; assuming side effects on a. Final Answer: b = 100 c = 200

Question 17

Uninitialized variable inside a conditional path: determine printed values  #include<stdio.h> int main() {  int a = 300, b, c;  if(a >= 400)  b = 300;  c = 200;  printf("%d, %d, %d ", a, b, c);  return 0; }

Accepted Answer

Introduction / Context: This checks understanding of definite assignment and reading uninitialized automatic variables. The program conditionally assigns to b but always prints it, regardless of whether the condition executed. Given Data / Assumptions: a = 300 so the condition a >= 400 is false. b is an automatic int with indeterminate initial value. c is assigned 200 before printing. Concept / Approach: In C, local automatic variables without an initializer contain indeterminate values. If the path that initializes b does not execute, printing b invokes undefined behavior (typically it appears as a “garbage” number). a and c are well-defined. Step-by-Step Solution: Evaluate condition: 300 >= 400 → false, so b is not set.Set c = 200.Print a (300), b (indeterminate), c (200). Verification / Alternative check: Initialize b to a known value (e.g., int b = 0;) to get deterministic output 300, 0, 200. Alternatively, place an else branch that initializes b when the if is false. Why Other Options Are Wrong: “300, 300, 200” assumes the if branch executed. “Garbage, 300, 200” misplaces the garbage value on a, which is initialized. “300, 300, Garbage” is wrong because c is definitely assigned. Common Pitfalls: Assuming locals default to 0; forgetting that reading an uninitialized variable is undefined; misinterpreting compiler warnings as safe behavior. Final Answer: 300, Garbage, 200

Question 18

Ternary operator used as a format selector in printf: what is printed?  #include<stdio.h> int main() {  char str[] = "C-program";  int a = 5;  printf(a > 10 ? "Ps " : "%s ", str);  return 0; }

Accepted Answer

Introduction / Context: This question evaluates whether you recognize that the conditional operator here is selecting the printf format string, not the value printed. It is a common interview trick to test understanding of printf arguments. Given Data / Assumptions: a = 5, so the condition a > 10 is false. Two possible format strings: "Ps" and "%s". Extra argument str is passed either way. Concept / Approach: Because the ternary returns a single selected format string, when the condition is false, the format is "%s". The variadic argument list includes str, so printf prints the character array as a C string. No formatting error occurs because the chosen format matches the provided argument. Step-by-Step Solution: Evaluate condition: 5 > 10 → false.Select format: "%s".Call printf("%s", str) → prints the contents of str → "C-program". Verification / Alternative check: Change a to 11. Then the format becomes "Ps" and printf is called with an extra, unused argument. This is allowed in C; the extra argument is ignored. Output would be "Ps". Why Other Options Are Wrong: “Ps” would require a > 10. “Error/None/No output” are incorrect because the code compiles and produces the expected string. Common Pitfalls: Thinking the second argument is conditionally present; believing mismatched arguments cause automatic errors (they can cause UB if format specifiers do not match, but here they do match). Final Answer: C-program

Question 19

Loop control with a signed char counter: how many values print?  #include<stdio.h> int main() {  char j = 1;  while(j < 5)  {  printf("%d, ", j);  j = j + 1;  }  printf(" ");  return 0; }

Accepted Answer

Introduction / Context: This problem examines loop termination with a small integer type. Despite j being a char, the condition is simple and the loop terminates deterministically, illustrating that signedness only matters when overflow or wrap-around could occur. Given Data / Assumptions: j starts at 1. The loop increments j until it is no longer less than 5. We assume typical 8-bit char, but it does not matter here because values remain small. Concept / Approach: The body prints j, then increments by 1. The condition is checked again. As soon as j reaches 5, j < 5 becomes false and the loop ends. No overflow occurs because j stays within 1..5. Step-by-Step Solution: Iteration 1: j=1 → print “1, ” → j=2.Iteration 2: j=2 → print “2, ” → j=3.Iteration 3: j=3 → print “3, ” → j=4.Iteration 4: j=4 → print “4, ” → j=5.Check condition: 5 < 5 → false → exit; newline printed. Verification / Alternative check: Had the loop been while(j >= 0) with unsigned char, wrap-around could cause an infinite loop. But with a strict upper bound of 5, no wrap-around is reached. Why Other Options Are Wrong: Long sequences to 127/255 imply missing termination; the program clearly terminates at 4. “Infinite times” is not applicable. Common Pitfalls: Assuming char arithmetic will wrap in any short loop; forgetting exact loop condition logic; misreading the output formatting (commas and spaces are cosmetic). Final Answer: 1, 2, 3, 4

Question 20

Is continue allowed directly inside a switch statement without an enclosing loop?  #include<stdio.h> int main() {  int i=3;  switch(i)  {  case 1:  printf("Hello ");  case 2:  printf("Hi ");  case 3:  continue;  default:  printf("Bye ");  }  return …

Accepted Answer

Introduction / Context: This question checks knowledge of valid control statements inside a switch. While break and goto are common within a switch, continue is only meaningful within loops (for, while, do-while). Given Data / Assumptions: continue appears directly in a switch within main, not inside any loop. Compiler follows standard C rules for control flow statements. Concept / Approach: continue transfers control to the next loop iteration. Without an enclosing loop, the statement has no valid target and is ill-formed. Most compilers emit an error such as “continue statement not within a loop” or “misplaced continue”. Step-by-Step Solution: Parse the switch: cases 1, 2, and 3 exist; default also exists.Encounter continue; in case 3 without an enclosing loop.Compilation fails with an error about continue’s placement. Verification / Alternative check: Wrap the switch inside a loop to make continue valid: e.g., while(1){ switch(i){ ... case 3: continue; }} Now continue would jump to the next loop iteration. Why Other Options Are Wrong: No runtime output occurs because compilation fails. Therefore options suggesting printed lines or a hang are incorrect. Common Pitfalls: Confusing break (valid in switch) with continue (loop-only); thinking continue behaves like break in a switch. Final Answer: Error: Misplaced continue

Control Instructions Questions