Question 1

For the following C program, what is the most appropriate description of its behaviour? int *m() {     int *p = 5;  /* attempt to assign an integer constant to a pointer */     return p; } int main() {     int *k = m();     printf("%d", k);     retu…

Accepted Answer

Introduction / Context:This question examines pointer initialization rules in C and what happens when you assign an arbitrary integer constant to a pointer. Understanding what is allowed and what should be rejected by the compiler is essential for writing safe, portable C code. Given Data / Assumptions: The function m declares int *p and initializes it with the integer constant 5. m returns this pointer value to main, where it is stored in k. main then calls printf with format "%d" and passes k. Concept / Approach:In standard C, only the integer constant 0 has a special meaning when assigned to a pointer, producing the null pointer. Assigning any other integer value to a pointer without an explicit cast is not a usual, well defined operation and is at best highly non portable. Good compilers treat assignment of a nonzero integer constant to a pointer of unrelated type as a constraint violation and issue a diagnostic, often treating it as an error when warnings are elevated. Even if the code were forced to compile, printing a pointer with the integer format "%d" would be undefined behaviour. Step-by-Step Solution:Step 1: Look at int *p = 5;. This attempts to assign the integer 5 directly to a pointer to int.Step 2: According to the language rules, only 0 is guaranteed to convert to a valid null pointer without a cast. Other integer values require explicit casts and may still produce invalid addresses.Step 3: A conforming compiler is expected to diagnose this as an invalid initialization, at least with a warning. In many teaching contexts this is treated as a compilation error.Step 4: Because of this, the most appropriate description is that the program does not compile cleanly, rather than focusing on hypothetical runtime output. Verification / Alternative check:If you try to compile such code with warnings enabled, typical compilers emit messages like "incompatible integer to pointer conversion" for the line initializing p. If warnings are treated as errors, the build fails, which matches the chosen answer. Why Other Options Are Wrong:Option A assumes that 5 becomes both a valid pointer and a correctly printed integer, which is not guaranteed or portable.Option B discusses junk values or crashes, which may happen if the code is forced to compile, but this ignores the more fundamental compile time issue.Option C is incorrect because uninitialized pointers do not automatically become null; in this case the pointer is explicitly initialized with 5. Common Pitfalls:Programmers sometimes treat pointers and integers as freely interchangeable, which is dangerous and non portable. Only the conversion of 0 to a null pointer is defined and safe in this simple way. Printing pointers also requires the %p format and a cast to void *, not %d. Final Answer:The best description is A conforming C compiler should diagnose assigning the integer 5 to an int * without a cast as an error, so the program does not compile cleanly.

Question 2

In the following C program using an extern declaration, what happens at compile and link time? int main() {     extern int i;     i = 20;     printf("%d", sizeof(i));     return 0; }

Accepted Answer

Introduction / Context:This question tests your understanding of storage class specifiers, the extern keyword, and how the linker resolves global symbols. It also touches on the fact that sizeof operates on types and objects, not on their storage locations. Given Data / Assumptions: Inside main, there is a declaration extern int i; which declares i as a global integer defined elsewhere. The program then assigns i = 20; and prints sizeof(i). No definition of i appears in this translation unit or any other object file. Concept / Approach:The extern keyword in this context tells the compiler that the variable i has external linkage and that its definition will be provided in some other translation unit. The compiler uses this information to compile references to i, but it does not allocate storage. When the program is linked, the linker must find exactly one definition of i. Because no such definition exists, the linker reports an undefined reference error. The expression sizeof(i) can be evaluated using the known type int, but the assignment i = 20 requires that storage for i actually exist, so the missing definition is a fatal problem. Step-by-Step Solution:Step 1: The compiler sees extern int i; and records that i is an externally defined int.Step 2: The compiler generates code for i = 20; and sizeof(i) using the type information, assuming that a definition will exist at link time.Step 3: During linking, the linker attempts to resolve the symbol i.Step 4: Because there is no definition such as int i; in any object file, the linker reports an undefined symbol or unresolved external for i.Step 5: The executable is not produced, so nothing runs and no output appears. Verification / Alternative check:Compiling this code as a standalone program on a typical toolchain produces a link-time error such as "undefined reference to i". If you add a global definition int i; outside main, the program links and runs, printing the size of int. Why Other Options Are Wrong:Option A ignores the requirement for a definition and incorrectly suggests successful linking.Option C is incorrect because sizeof works with extern variables; sizeof is based on type, not storage location.Option D mentions a runtime crash, but the program never reaches runtime because the link step fails. Common Pitfalls:Many learners think extern both declares and defines storage, which is not true. extern at block scope usually only declares the variable. A separate definition without extern is required in exactly one translation unit. Final Answer:The correct description is The program fails at link time with an undefined reference to i, because i is declared extern but never defined in any translation unit.

Question 3

In C at file scope, what is the difference between the declarations extern int fun(); and int fun(); when no definition appears in the same translation unit?

Accepted Answer

Introduction / Context:This question checks your understanding of function declarations, extern, and linkage in C. Many programmers are confused about when extern is necessary and what default linkage rules apply to functions declared at file scope. Given Data / Assumptions: Both declarations appear at file scope, outside of any function. No function definition for fun appears in the same translation unit. We are comparing the meaning of extern int fun(); and int fun();. Concept / Approach:In C, a function declaration at file scope without a storage class specifier, such as int fun();, has external linkage by default. That means the function can be defined in this or another translation unit and can be called from other files. Adding extern explicitly, as in extern int fun();, does not change the meaning for functions; it simply makes the external linkage explicit. In both cases, these lines are declarations, not definitions, because they do not provide a function body. Step-by-Step Solution:Step 1: Consider int fun(); at file scope. This declares a function named fun that returns int and has external linkage by default.Step 2: Consider extern int fun(); at file scope. This also declares the same function signature with external linkage, making the linkage explicit.Step 3: Neither line has a function body enclosed in braces, so neither is a definition.Step 4: From the perspective of the compiler and linker, both declarations are compatible and interchangeable function prototypes for the same external function. Verification / Alternative check:If you place either declaration in a header file and define fun in a separate C file, the program links and runs correctly. Switching between the two forms or using both in different translation units does not change behaviour, demonstrating that there is no practical difference in this context. Why Other Options Are Wrong:Option B incorrectly claims that int fun(); defines the function, but a definition in C requires a function body.Option C confuses functions and variables; the presence of parentheses clearly indicates a function declaration.Option D is false because extern int fun(); is valid C syntax and is commonly used. Common Pitfalls:Programmers sometimes overuse extern for functions, not realizing that it is usually redundant at file scope. The real place where extern is important is for variables with external linkage, where it separates declarations from the single definition. Final Answer:The correct statement is There is effectively no difference: both declare fun as a function that returns int and has external linkage, and neither one by itself provides a definition.

Question 4

In the following C program that uses a function pointer, what is the error? void fun() {     printf("Loud and clear"); } int main() {     int (*p)() = fun;     (*P)();     return 0; }

Accepted Answer

Introduction / Context:This question checks understanding of case sensitivity in C, function pointers, and correct identifier usage. It presents code that attempts to call a function through a pointer but introduces a subtle error in the spelling of the pointer variable. Given Data / Assumptions: There is a function fun that prints a message. A function pointer p is declared and initialized as int (*p)() = fun;. The code attempts to call (*P)(); instead of (*p)();. Concept / Approach:C is a case sensitive language. This means that identifiers such as p and P are distinct names. Declaring int (*p)() = fun; introduces a pointer variable named p, but it does not introduce any variable named P. When the compiler encounters (*P)();, it will look for a declaration of P and will not find one, which results in an error about an undeclared identifier. Step-by-Step Solution:Step 1: The line int (*p)() = fun; correctly declares and initializes a function pointer p that can point to fun.Step 2: The intended call to the function through the pointer should use p, for example p(); or (*p)();.Step 3: The code instead writes (*P)(); with an uppercase P.Step 4: Since P has never been declared, the compiler will report an error such as "P undeclared" or "use of undeclared identifier P". Verification / Alternative check:If you correct the code to use (*p)(); or simply p();, the program compiles and runs, printing "Loud and clear". This confirms that the only real issue is the mistaken use of P instead of p. Why Other Options Are Wrong:Option B is incorrect because function pointers can be assigned and int (*p)() = fun; is valid C.Option C is false because calling functions through pointers is a standard and supported feature in C.Option D is incorrect in modern C; int main() is the standard signature and void main is not recommended. Common Pitfalls:Case sensitivity errors are common in C, especially when variable names differ only in capitalization. Careful, consistent naming and the use of compiler warnings help catch such mistakes quickly. Final Answer:The error is that The identifier P in the call (*P)() has not been declared; C is case sensitive, so P is different from the declared pointer p.

Question 5

In the following C program, what is wrong with the while loop? int main() {     int i = 1;     while () {         printf("%d", i++);         if (i > 10) break;     }     return 0; }

Accepted Answer

Introduction / Context:This question is about the correct syntax of the while loop in C. It highlights that while requires a condition expression inside its parentheses, even if the intention is to loop forever. Given Data / Assumptions: The program declares an integer i and initializes it to 1. The while statement is written as while (). Inside the loop, the program prints i and increments it, exiting when i becomes greater than 10. Concept / Approach:In C, the syntax of a while loop is while (expression) statement;. The expression must be present and must be something that the compiler can evaluate as true or false (nonzero or zero). An empty pair of parentheses is not valid syntax. If a programmer wants an infinite loop, they usually write while (1) or while (true) in C with appropriate definitions. Step-by-Step Solution:Step 1: Inspect the while line. It is written as while ().Step 2: The grammar for C requires an expression between the parentheses.Step 3: Because no expression is present, the compiler cannot parse this as a valid while loop.Step 4: The compiler will emit a syntax error pointing at the while statement. Verification / Alternative check:If you attempt to compile this program, the compiler will reject it and indicate an error near while (). If you change the line to while (1) and keep the break condition, the loop runs and prints numbers from 1 to 10, demonstrating what the programmer may have intended. Why Other Options Are Wrong:Option B is incorrect because break is allowed inside while loops.Option C is false; using i++ inside printf is allowed, though it must be used carefully in more complex expressions.Option D is incorrect because nesting if inside while is perfectly legal and common. Common Pitfalls:Some beginners think they can leave the while condition empty to indicate an infinite loop, similar to for(;;) syntax. However, while does not allow an empty condition; an explicit expression such as 1 is required. Final Answer:The issue is that The while loop has an empty condition, which is a syntax error; a valid expression must appear inside the parentheses.

Question 6

Point out the error in the following C program that uses a switch statement and a variable in a case label: int main() {     int i = 4, j = 2;     switch (i) {         case 1:             printf("To err is human, to forgive is against company policy…

Accepted Answer

Introduction / Context:This question tests understanding of the rules for case labels in a switch statement in C. It focuses on the requirement that case labels be constant expressions known at compile time. Given Data / Assumptions: The switch expression is the integer variable i with value 4. There is a case 1 label. There is a case j label where j is a variable with value 2. We assume standard C compilation rules. Concept / Approach:According to the C standard, each case label in a switch must be a constant integer expression that the compiler can evaluate at compile time. Examples include literal integers, enumeration constants, or expressions composed only of constants and operators. A plain variable such as j is not a constant expression. Therefore, case j is not valid as a case label. Step-by-Step Solution:Step 1: Identify the case labels in the switch statement: case 1 and case j.Step 2: case 1 is fine because 1 is a constant integer expression.Step 3: case j uses a variable j. The value of j is not a compile time constant expression.Step 4: The compiler must reject case j as an invalid case label, producing a diagnostic message. Verification / Alternative check:If you compile this program with a standard C compiler, you will receive an error similar to "case label does not reduce to an integer constant". If you change case j to case 2, the program compiles correctly, showing that the problem is specifically the use of a variable as a case label. Why Other Options Are Wrong:Option B is incorrect because the switch expression can legally be an int; it does not need to be char.Option C is false because printf can be used inside switch cases like any other statement.Option D is incorrect because a default label is optional in C; omitting it is allowed. Common Pitfalls:Programmers sometimes try to use variables or nonconstant expressions as case labels to make code more flexible. This is not allowed in standard C. If a dynamic decision is needed, it must be implemented with if or else logic rather than case labels. Final Answer:The error is that case j is invalid because case labels must be constant integer expressions, not variables.

Question 7

What is the output of the following C program that uses a static array and the post-increment operator? int main() {     static int a[20];     int i = 0;     a[i] = i++;     printf(" %d%d%d", a[0], a[1], i);     return 0; }

Accepted Answer

Introduction / Context:This question illustrates the behaviour of static arrays, default initialization, and the post increment operator used in an assignment. It requires careful evaluation of a[i] = i++ and understanding of the resulting values. Given Data / Assumptions: a is declared as static int a[20]; so all elements are zero initialized by default. i is initialized to 0. The statement a[i] = i++; uses i both as an index and as a value in a post increment expression. The printf call prints a[0], a[1], and i with no spaces between the %d conversions, preceded by a newline. Concept / Approach:In C, the expression i++ evaluates to the current value of i, then increments i as a side effect. Since i is used as an array index, we must use its value before and after the increment carefully. Because a is static, any element that is not explicitly assigned remains zero. We need to compute the values of a[0], a[1], and i after the assignment. Step-by-Step Solution:Step 1: Initially, i is 0 and all elements of a are 0.Step 2: Evaluate a[i] = i++;. The index expression i uses the current value 0, so we are assigning to a[0].Step 3: The right-hand side i++ evaluates to 0 as a value, and then i is incremented to 1.Step 4: After this statement, a[0] is set to 0, i is now 1, and a[1] is still 0 because it has never been assigned.Step 5: The printf call prints a newline, then a[0], a[1], and i. Thus it prints 0, 0, and 1 with no spaces, resulting in 001 after the newline. Verification / Alternative check:You can rewrite the core logic as temp = i; a[i] = temp; i = i + 1; to see that a[0] receives 0 and i becomes 1. Running such a program in a compiler produces the expected output. Why Other Options Are Wrong:Option B would require a[0] to be 1, which is not the case.Option C suggests a[1] becomes 1, but a[1] is never modified and remains 0.Option D would require both a[0] and a[1] to be changed to 1, which does not happen. Common Pitfalls:Programmers sometimes misread post increment expressions and think the value used on the right side is the incremented value. Remember that i++ yields the old value, then increments i after evaluation. Final Answer:The program prints Newline followed by 0 0 1 (printed contiguously as 001).

Question 8

In the following C program, what is the correct description of its behaviour? int main() {     int i = 2;     printf(" %d%d", ++i, ++i);     return 0; }

Accepted Answer

Introduction / Context:This question tests your understanding of undefined behaviour in C, specifically related to modifying a variable multiple times without an intervening sequence point. It is a common trap in exams because some compilers appear to give a predictable result even though the language standard does not guarantee it. Given Data / Assumptions: i is initialized to 2. The printf call is printf("%d%d", ++i, ++i);. The order of evaluation of function arguments in C is unspecified. Concept / Approach:In C, if you modify a scalar variable more than once without an intervening sequence point and then read its value, the behaviour is undefined. The call printf("%d%d", ++i, ++i); increments i twice in the same full expression, and the standard does not specify whether the left or right argument to printf is evaluated first. As a result, different compilers, or even different optimization levels of the same compiler, may produce different results, and some behaviours may be surprising. Step-by-Step Solution:Step 1: Recognize that both arguments ++i and ++i modify the same variable.Step 2: The C standard does not define the order in which these arguments are evaluated.Step 3: Because i is modified more than once without a sequence point between these modifications and is also read to produce the argument values, the expression exhibits undefined behaviour.Step 4: Undefined behaviour means that the program may print different numbers such as 34 or 43, or may exhibit other unexpected results. Verification / Alternative check:If you compile and run this program with different compilers, or with different optimization flags, you may observe different outputs. This variation confirms that there is no portable, well defined result. Why Other Options Are Wrong:Option A and option B both claim a specific fixed output, which is not guaranteed by the language.Option D is incorrect because the syntax is valid; the issue is semantic undefined behaviour, not a compilation error. Common Pitfalls:Many programmers assume that arguments are evaluated left to right, but C does not require this. It is best to avoid writing expressions that both modify and use a variable more than once in a single expression. Final Answer:The correct description is The behaviour is undefined, so the printed values may vary between compilers or runs.

Question 9

In standard C, what can you say about the order in which the functions f1, f2, and f3 are called in the following expression? a = ( f1(23, 14) * f2(12 / 4) ) + f3();

Accepted Answer

Introduction / Context:This question explores the concept of unspecified order of evaluation in C. It is related to expressions that contain multiple function calls whose results are combined. Understanding this concept is essential for writing portable and predictable C code. Given Data / Assumptions: The expression is a = ( f1(23, 14) * f2(12 / 4) ) + f3();. f1, f2, and f3 have no side effects that would allow you to deduce the order from context. We assume standard C rules for expression evaluation. Concept / Approach:In C, the order of evaluation of most subexpressions is unspecified unless the standard explicitly defines it. For operators such as + and *, the standard does not guarantee whether the left operand is evaluated before the right operand. This means that a compiler is free to call f3 before or after f1 and f2, and it can evaluate f2 before f1 or vice versa, as long as the final result of the arithmetic operations is as if all subexpressions were evaluated and combined correctly. Step-by-Step Solution:Step 1: Identify the subexpressions: f1(23, 14), f2(12 / 4), and f3().Step 2: The multiplication and addition operators do not impose a specific evaluation order on their operands.Step 3: The compiler is allowed to evaluate f3() before the product, after the product, or interleaved in any way, provided it respects sequence points and produces a mathematically correct combination of results.Step 4: Therefore, the language standard explicitly leaves the order of calls to f1, f2, and f3 unspecified. Verification / Alternative check:If you instrument f1, f2, and f3 to print which function is called, and then compile with different compilers or optimization levels, you may observe different call orders. This experiment demonstrates that there is no guaranteed sequence. Why Other Options Are Wrong:Option A and option B claim specific orders, which the standard does not guarantee.Option D is misleading; while compilers can optimize code, they are not allowed to remove function calls that may have observable effects unless they can prove the calls are side effect free and unused. The question assumes ordinary functions. Common Pitfalls:Programmers sometimes rely on an observed evaluation order from a particular compiler. This is dangerous because another compiler or optimization flag may change the order. It is best to avoid relying on evaluation order when functions have side effects. Final Answer:The correct statement is The C standard does not specify a fixed order; the compiler is free to evaluate the subexpressions in any order, so the function call order is unspecified.

Question 10

In the following C program that reads an array of structures, which problem are you most likely to encounter at runtime? int main() {     struct emp {         char name[20];         float sal;     };     struct emp e[10];     int i;     for (i = 0; …

Accepted Answer

Introduction / Context:This question focuses on safe input handling in C, especially when reading strings into fixed size character arrays inside structures. Misuse of scanf with %s can easily lead to buffer overflows, which are serious security and stability problems. Given Data / Assumptions: Each struct emp has a name array of 20 chars and a float sal. An array e of 10 such structures is declared. A loop reads 10 pairs of values using scanf("%s %f", e[i].name, &e[i].sal);. Users may type arbitrary length names at the console. Concept / Approach:The %s conversion in scanf reads a sequence of non whitespace characters into the provided char array and appends a terminating zero byte. However, %s does not automatically know the size of the destination buffer. If the user types more characters than the buffer can hold (including the terminating zero), scanf will write past the end of the array. In this program, name has room for at most 19 visible characters plus the terminating zero. Without a field width limit in the format string, there is a real risk of overflowing the buffer. Step-by-Step Solution:Step 1: Consider a user who types a short name such as "Bob". This fits safely in name and the program behaves normally.Step 2: Now consider a user who types a very long token such as "VeryLongEmployeeNameExceedingLimit".Step 3: scanf with %s will attempt to copy all of these characters into name, exceeding its 20 byte capacity.Step 4: This overwrites adjacent memory, potentially corrupting the e array, local variables, or even control data such as the stack frame.Step 5: Such corruption may lead to crashes or security vulnerabilities. Verification / Alternative check:A safer approach is to specify a maximum field width such as "%19s %f" so that scanf never writes more than 19 characters plus the terminating zero into name. Using this safer format removes the overflow risk for well formed input. Why Other Options Are Wrong:Option B is incorrect because passing e[i].name to scanf is valid; arrays decay to pointers, and scanf expects char * for %s.Option C is wrong because the loop condition i <= 9 correctly iterates 10 times.Option D is incorrect because for scanf, %f is the correct specifier for reading a float; %lf is used when reading a double. Common Pitfalls:Programmers often forget to include field width limits in scanf format strings. It is safer to use fgets followed by parsing, or to ensure that every %s includes a width that matches the destination buffer size minus one. Final Answer:The main likely problem is There is a risk of buffer overflow and memory corruption if the user types a name longer than 19 characters, because %s has no field width limit for the 20 byte array.

Question 11

What is the output of the following C program on a typical system where sizeof(float) is 4 bytes and sizeof(double) is 8 bytes? int main() {     printf(" %d%d%d ", (int)sizeof(3.14f), (int)sizeof(3.14), (int)sizeof(3.141));     return 0; }

Accepted Answer

Introduction / Context:This question checks understanding of literal types in C and the behaviour of sizeof when applied to floating point constants. It also requires careful reading of the printf format string. Given Data / Assumptions: 3.14f is a float literal. 3.14 and 3.141 are double literals by default. On the target system, sizeof(float) is 4 and sizeof(double) is 8. The printf format string is " %d%d%d " and each sizeof result is cast to int. Concept / Approach:In C, a floating literal without a suffix (such as 3.14) has type double. Adding the suffix f or F changes its type to float. Therefore sizeof(3.14f) yields the size of float and sizeof(3.14) and sizeof(3.141) both yield the size of double. The printf call prints the three sizes back to back with no spaces between the %d conversions, except for a leading and trailing space from the literal string. Step-by-Step Solution:Step 1: Evaluate sizeof(3.14f). Since 3.14f is a float literal, sizeof(float) is 4 bytes on the given system.Step 2: Evaluate sizeof(3.14). Since 3.14 is a double literal, sizeof(double) is 8 bytes.Step 3: Evaluate sizeof(3.141). This is also a double literal, so sizeof(double) is again 8 bytes.Step 4: The three integer values are 4, 8, and 8. The format " %d%d%d " prints a leading space, then 4, then 8, then 8, and finally a trailing space.Step 5: As text, this appears as space, 4, 8, 8, space, which we can summarize as " 488 ". Verification / Alternative check:If you compile and run the program on a typical 32 bit or 64 bit platform that uses IEEE single and double precision, the output will be exactly a space, then 4, 8, and 8 with no internal spaces, then a space. This confirms the analysis. Why Other Options Are Wrong:Option B incorrectly assumes all literals are float, which is not true without the f suffix.Option C incorrectly assumes all literals are double, ignoring the f suffix on 3.14f.Option D is wrong because sizeof can be applied to any expression, including floating constants. Common Pitfalls:Programmers sometimes forget that unsuffixed floating literals are double, not float, which can affect precision and size. Another pitfall is misreading printf strings and assuming there are spaces between all %d placeholders when there are not. Final Answer:The program prints 488 (space, then 4 8 8, then a trailing space).

Question 12

What would be the output of the following C program that compares a float value initialised with 0.7 to the float literal 0.7f in an if condition?  main() {     float a = 0.7;     if (a < 0.7f)         printf("C");     else         printf("C++"); }

Accepted Answer

Introduction / Context: In C programming, floating point comparisons often behave in surprising ways because decimal fractions usually cannot be represented exactly in binary. This question tests understanding of how float and double literals are stored, how literals like 0.7 and 0.7f differ, and how that affects a relational comparison inside an if statement. It also checks whether the learner can reason about what the program actually prints when using printf with these floating values in a conditional expression. Given Data / Assumptions: - The variable a is declared as float and initialised with the literal 0.7. - The comparison in the if condition is a < 0.7f, where 0.7f is a float literal. - We assume the program is corrected to use printf with proper headers, so we focus on the floating point behaviour rather than header issues. - The environment follows the usual IEEE 754 representation for float and double values. Concept / Approach: In C, the literal 0.7 without a suffix is of type double. When it is assigned to a float variable, its value is converted to float, which has less precision than double. The literal 0.7f is already of type float and is rounded according to float precision. Due to the way compilers handle constants, the conversion of 0.7 to float for the assignment and the encoding of 0.7f as a float literal can end up with slightly different underlying bit patterns. The comparison a < 0.7f is therefore a comparison between two float values that are extremely close but not necessarily identical. If a is slightly smaller than 0.7f, the condition becomes true and the branch printing C is taken. Step-by-Step Solution: 1. The variable a is declared as float and initialised: a = 0.7; The double literal 0.7 is converted to float, losing some precision. 2. The literal 0.7f is encoded directly as a float constant, again with rounding to the nearest representable float value. 3. Because the compiler may round the assignment from 0.7 differently from the float literal 0.7f, the internal value stored in a can be slightly smaller than the value represented by 0.7f. 4. The if condition a < 0.7f is evaluated using float arithmetic. 5. If the stored value of a is slightly less than the value of 0.7f, the condition is true and the statement printf("C"); executes. 6. If the values had been exactly equal, the condition would be false and the else branch would print C++ instead. 7. On typical implementations that motivate this question, a is fractionally smaller, so the condition is true and the output is C. Verification / Alternative check: One way to conceptually verify this behaviour is to remember that float has fewer bits of precision than double. The literal 0.7 as double may be rounded to a slightly different float value when assigned to a than the direct float literal 0.7f used in the comparison. Many teaching compilers are set up so that the conversion during assignment and the encoding of the float literal do not match exactly, making a < 0.7f evaluate to true. This example is often used in interviews and exams to highlight that equality and relational comparisons on floating point numbers should be treated with caution. Why Other Options Are Wrong: Option B (C++) would be correct only if a and 0.7f always had identical float values so that the condition was false, but the example is specifically designed so that a is slightly smaller than 0.7f. Option C is incorrect because there is no control flow path that avoids printing; either the if or else branch will execute. Option D is incorrect because the types in the comparison are both float after usual conversions, so there is no compilation error caused by the if condition itself in a properly declared program. Common Pitfalls: A common mistake is assuming that 0.7 and 0.7f are exactly the same once used in float expressions, and therefore believing that a < 0.7f must be false. Another frequent confusion is to ignore floating point precision issues and think in terms of ideal real numbers. Many learners also focus on minor syntactic issues and conclude that the code will not compile, missing the conceptual point about floating point comparisons. In real projects, comparing floats for exact equality can be dangerous; a better practice is to compare the absolute difference to a small tolerance value. This question encourages deeper awareness of numeric precision and how literals of different types behave in C. Final Answer: The condition a < 0.7f evaluates to true on typical systems because of subtle float rounding differences, so the program prints C.

Question 13

In the following C program there is a mistake related to function declaration and type conversion. Which extra statement should be added before main to make the program correct and avoid implicit declaration problems?  main() {     int a;     a = f(…

Accepted Answer

Introduction / Context: This question checks understanding of function declarations, prototypes, and type compatibility in C. Older C compilers sometimes allowed implicit function declarations, but modern C standards require that every function be declared before it is used. When argument and return types are not properly declared, the compiler may assume incorrect defaults and cause undefined behaviour or compilation warnings and errors. Here, the code calls a function f before describing its full type, and the learner must identify which extra statement should be added to make the program well formed. Given Data / Assumptions: - A function f is defined with parameters aa and bb and returns a value based on aa and bb. - The call a = f(10, 3.14); appears inside main before any prototype for f is written. - The program intends to print the integer value stored in a using printf with the %d format specifier. - We assume a modern C compiler that follows the requirement that functions must be declared or defined before they are called. Concept / Approach: In C, a function prototype tells the compiler the function name, its return type, and its parameter types. This ensures that when the function is called, the compiler can check argument types and apply correct conversions. Without a prototype in scope, older C rules treated functions as implicitly returning int and performed default promotions on arguments. This can easily lead to mismatches between the caller and callee. The correct fix is usually to add a prototype that matches the actual definition of the function so that the compiler knows the correct signature at the call site. Step-by-Step Solution: 1. Examine the function definition: f(int aa, float bb) { return ((float) aa + bb); }. This function takes an int and a float and returns a floating point sum. 2. Note that main calls f as a = f(10, 3.14); without any previous prototype. This means the compiler cannot verify types correctly at that point. 3. In standard C practice, we should declare the function before main, using a prototype that exactly matches its definition. 4. The correct prototype is int f(int aa, float bb); because f ultimately returns a value that will be assigned to int a. The explicit cast inside the function can be adjusted if we want a pure int return, but the question focuses on the missing declaration. 5. Adding int f(int aa, float bb); before main informs the compiler about the correct parameter types and return type. 6. With this prototype, the call a = f(10, 3.14); becomes type checked. The double literal 3.14 is converted to float for the parameter bb as required. Verification / Alternative check: If we compile the original program without the prototype on a modern compiler with strict warnings, we are likely to see warnings about implicit declaration of function f or about incompatible types being returned or assigned. After adding the proper prototype, these warnings disappear, and the program becomes much more portable. In many code bases, compilation with warnings treated as errors would fail without the prototype. This confirms that adding the function declaration is the correct fix. Why Other Options Are Wrong: Option B, float f(float aa, float bb);, changes both the parameter and return types, which does not match the given definition and would require modifying the function body as well. Option C, void f(int aa, float bb);, declares the function as not returning any value, which conflicts with the actual return statement and makes assigning its result to a invalid. Option D, double f(int aa, double bb);, also mismatches the types and would force different conversions. Only option A preserves the intended signature and fixes the implicit declaration problem directly. Common Pitfalls: A frequent mistake is to rely on implicit int return types or to ignore compiler warnings about missing prototypes. Another pitfall is thinking that changing the function definition types is acceptable, without considering assignment to the variable a. Developers sometimes forget that prototypes must appear before any use of the function in the translation unit, not just somewhere in the file. This question reinforces the habit of always writing clear prototypes, either in header files or before main, to avoid subtle type mismatches and portability issues. Final Answer: You should add the function prototype int f(int aa, float bb); before main so that the call a = f(10, 3.14); is type checked correctly.

Question 14

In the following C program, what is the error that prevents it from compiling correctly, and how should it be fixed?  main() {     int a = 10;     void f();     a = f();     printf("%d", a); }  void f() {     printf("Hi"); }

Accepted Answer

Introduction / Context: This question focuses on function return types in C and on how void functions are intended to be used. It checks whether the learner understands that a void function does not return a value, and therefore its result cannot be assigned to a variable or used in expressions. Recognising this kind of error is important for reading and writing correct C code, and it is a common source of compiler diagnostics for beginners. Given Data / Assumptions: - The function f is declared as void f(); meaning it does not return any value. - Inside main, the integer variable a is initialised to 10 and then reassigned using a = f(); - The program calls printf to display the value of a after the call to f. - We assume that required headers such as stdio.h would be included in a complete program, and we focus here on the logical and type correctness of the code. Concept / Approach: In C, every function has a declared return type. A function with return type void does not produce a value that can be used in expressions. It is legal to call such a function as a standalone statement, but it is illegal to attempt to assign its result to a variable. The compiler enforces this by issuing an error when code tries to treat the result of a void function as a value. The correct approach is either to give the function a nonvoid return type and return a value explicitly, or to call the void function without assignment if no value is needed. Step-by-Step Solution: 1. Read the forward declaration void f();, which states that f takes no parameters (in modern style) and does not return any value. 2. Inside main, the code a = f(); attempts to call f and assign its result to the integer variable a. 3. Since f is void, there is no result value. The C type system does not allow converting a void expression into int in this way. 4. Most compilers will issue an error message such as void value not ignored as it ought to be, or a similar diagnostic. 5. To fix the program, either change the declaration and definition of f to return an int and add an appropriate return statement, or remove the assignment and simply call f(); without using its result. 6. For example, if the intent is just to print Hi and leave a unchanged, write f(); and then printf("%d", a);. Verification / Alternative check: If you compile a version of this code with a modern C compiler, you will see an error generated for the assignment of the void expression f() to a. Modifying f so that it returns an int, for example int f(void) { printf("Hi"); return 20; }, and then adjusting the declaration to int f(void); will remove this error. Alternatively, simply calling f(); without using its non-existent result also compiles. These checks confirm that the core problem is the illegal use of a void function in an assignment expression. Why Other Options Are Wrong: Option B is incorrect because there is no requirement that f be static; storage class keywords do not fix the return type problem. Option C is irrelevant to the specific error; while modern C standards require main to return int, that is not what prevents compilation in the given snippet. Option D is false because printf can be called inside any function body, including void functions, as long as stdio.h is included and the call is correct. Only option A correctly identifies that the program tries to assign the result of a void function to an int variable, which is not allowed. Common Pitfalls: Many beginners confuse returning from a function with printing from a function. They sometimes think that printing a value also counts as returning a value that can be used outside the function. Another common mistake is to ignore the declared return type and assume that any function can be used in expressions. This question emphasises the distinction between a function that returns a useful result and one that performs actions only. Paying attention to function prototypes and compiler diagnostics is essential in avoiding these issues. Final Answer: The error is that the program assigns the result of a void function to an int variable. The call should not be used in an assignment, or the function should be given a proper nonvoid return type. The correct choice is the program incorrectly assigns the result of a void function f() to the int variable a.

Question 15

In modern C programming, will the following function definitions compile and work correctly as written, and why?  f1(int a, int b) {     return (f2(20)); }  f2(int a) {     return (a * a); }

Accepted Answer

Introduction / Context: This question examines how C handles function declarations, return types, and call order. In older C dialects it was sometimes legal to omit explicit return types, and the compiler would assume an int return type by default. However, modern C standards require explicit return type declarations and discourage implicit assumptions. The example also demonstrates the importance of providing a prototype or earlier definition for a function like f2 before it is called by another function such as f1. Given Data / Assumptions: - The functions f1 and f2 are written without explicit return types before their names. - f1 calls f2 with the argument 20 and attempts to return the value produced by f2. - f2 takes an int parameter and returns the product a * a. - There is no prior prototype for f2 before its use inside f1. - We assume a modern C compiler that follows current language rules rather than very old implicit int behaviours. Concept / Approach: Under current C standards, every function definition must include an explicit return type. Omitting the return type is not allowed, and relying on the compiler to guess a type is considered an error. Additionally, if one function calls another, the compiler needs to know the callee signature at the point of call, which is achieved by placing a prototype or full definition before the call. Without this, the compiler cannot reliably perform type checking. Therefore, the given code as written is not valid modern C and needs corrections to compile correctly. Step-by-Step Solution: 1. Examine the definition of f1: f1(int a, int b) { return (f2(20)); }. There is no explicit return type specified before f1. 2. Examine the definition of f2: f2(int a) { return (a * a); }. Similarly, there is no explicit return type before f2. 3. In modern C, both functions must have a declared return type, such as int f1(int a, int b) and int f2(int a). 4. At the point where f1 is compiled, the definition of f2 appears later in the source, and there is no preceding prototype telling the compiler about f2. 5. Without a prototype and with missing return types, the compiler cannot correctly apply the language rules and will report errors. 6. The correct approach is to write int f2(int a); before f1, and then define int f1(int a, int b) { return f2(20); } and int f2(int a) { return a * a; }. Verification / Alternative check: If you add explicit return types and a prototype, the code becomes straightforward: f2 squares its argument, and f1 always returns f2(20), which is 400. Compiling the original code without return types and prototypes on a strict compiler will result in errors rather than just warnings. This comparison confirms that the problem lies in missing type information and the call order rather than in the idea of one function calling another. Why Other Options Are Wrong: Option B is incorrect because in modern C the code will not always just work; missing return types and prototypes are not acceptable practice and often cause compilation failure. Option C is wrong because C fully supports calling one function from another; this is a basic feature of the language. Option D is misleading because the correctness of the code does not depend on the sign of the parameters. The real issue is the lack of explicit types and prototypes, as described in option A. Common Pitfalls: A typical mistake is relying on outdated examples that omit return types and assuming they are still correct today. Another pitfall is believing that the compiler will always infer the right types automatically, which may hide subtle bugs or cause undefined behaviour. Developers sometimes forget that function prototypes are essential for type checking, especially when compiling with strict warning levels or using separate compilation units. This question reinforces the habit of always declaring clear function signatures and placing prototypes before use. Final Answer: As written, the functions are missing explicit return types and lack a prototype for f2 before its use, so the code is not correct in modern C. The correct choice is no, because both functions are missing an explicit return type and there is no prototype for f2 before it is called.

Question 16

In the following C code, the SWAP macro is intended to swap two integer variables, but it is defined incorrectly. After macro expansion, will this code compile successfully, and what is the main problem with the macro definition?  #define SWAP(a, b,…

Accepted Answer

Introduction / Context: Macros in C are expanded by the preprocessor before compilation, and their definitions must form valid C code once expanded. This question checks understanding of macro parameter lists, macro bodies, and the difference between type names and expressions. The given SWAP macro aims to swap two integer variables but uses a third parameter to represent the type and combines it with local variable syntax in a problematic way. Learners must recognise why this macro does not expand to valid code and therefore fails to compile. Given Data / Assumptions: - The macro is defined as #define SWAP(a, b, c) (c t; t = a, a = b, b = t;). - Inside main, two integers x and y are declared and initialised to 10 and 20 respectively. - The macro is invoked as SWAP(x, y, int); intending to use int as the type parameter c. - The printf call aims to print the values of x and y after the macro is expanded and executed. - We assume a standard C compiler that applies macro expansion and then compiles the resulting code. Concept / Approach: A C macro performs simple textual substitution. Each occurrence of a macro parameter in the body is replaced with the corresponding argument text. For the code to compile, the expanded text must form valid C statements. In this case, the macro body starts with (c t; t = a, a = b, b = t;), which, when c is int, becomes (int t; t = x, x = y, y = t;). That pattern is not a valid single expression and does not represent a properly scoped declaration statement in C. Also, mixing a type name as a macro parameter with the rest of the expression is error prone and poorly structured. Step-by-Step Solution: 1. Substitute the parameters a, b, and c with x, y, and int in the macro body. 2. The expansion SWAP(x, y, int); becomes (int t; t = x, x = y, y = t;); after substitution. 3. The outer parentheses enclose what looks like multiple statements and a declaration, which is not allowed as a single expression in C. 4. Declaring int t; inside parentheses is invalid syntax; declarations must appear in a block or at file scope, not inside an expression list. 5. The comma operator inside t = x, x = y, y = t is legal for expressions, but the presence of the declaration int t; at the same level breaks the grammar. 6. As a result, the compiler encounters syntax errors when attempting to compile the expanded macro, and the code does not build successfully. Verification / Alternative check: A correct swap macro using a type parameter might look like this: #define SWAP(a, b, type) do { type tmp = (a); (a) = (b); (b) = tmp; } while (0). This pattern uses a temporary variable of the specified type inside a do while(0) block, forming valid C statements. Comparing this standard pattern with the flawed version in the question highlights the missing block structure and the incorrect use of parentheses. Trying to compile the original macro definition in a real compiler will produce syntax errors, confirming that the macro is not valid. Why Other Options Are Wrong: Option B claims that the macro compiles and swaps x and y correctly, which is false because the syntax errors prevent compilation. Option C suggests that the code compiles but does not swap, which is also incorrect because compilation fails before runtime behaviour can be observed. Option D is wrong because macros in C can take any number of parameters; the problem is not the parameter count but the misuse of the type parameter and invalid syntax in the macro body. Only option A correctly states that the macro does not compile due to invalid syntax and misuse of parameter c as a type in this context. Common Pitfalls: Programmers often underestimate the simplicity of macro substitution and expect the preprocessor to enforce language rules, which it does not. A common mistake is to combine declarations and expressions inside a macro without wrapping them in a proper block. Another pitfall is using extremely generic names like a, b, c for both values and types, which can make macro expansions confusing and error prone. This question encourages safer macro design or, better yet, the use of inline functions when possible in modern C and C plus plus code instead of complex macros. Final Answer: The macro expands to invalid C code that mixes a type declaration and expressions inside parentheses, so the program does not compile. The correct statement is that it will not compile because the macro body has invalid syntax and misuses the type parameter c.

Question 17

What would be the output of the following C program, assuming that: - The 2D array a has base address 1002 in memory - Each int occupies 2 bytes - The compiler prints addresses in decimal  main() {     int a[3][4] = {         {1,  2,  3,  4},       …

Accepted Answer

Introduction / Context: This question tests understanding of how multidimensional arrays are stored in memory in C and how pointer arithmetic works with such arrays. When you declare a 2D array of int values, the compiler lays them out contiguously in row major order. Expressions like a[0] + 1 and *(a[0] + 1) involve pointer arithmetic and dereferencing. The question also assumes specific starting addresses and a particular size of int to make the numeric output predictable. Given Data / Assumptions: - The array a is declared as int a[3][4] with initialiser values from 1 to 12 in row major form. - The base address of a[0][0] is assumed to be 1002. - Each int occupies exactly 2 bytes. - The expression a[0] refers to the address of the first element in the first row, that is the address of a[0][0]. - The printf uses the %u format specifier to print addresses and integer values as unsigned integers. Concept / Approach: In C, a multidimensional array like int a[3][4] is stored as a contiguous block of 3 * 4 = 12 integers. The name a in expressions decays to a pointer to its first row, and a[0] is a pointer to the first element of that row. Pointer arithmetic on int pointers increments or decrements the address by the size of int in bytes. Dereferencing such expressions retrieves the stored integer values. To find the printed output, we compute the address and values step by step, using the given base address and element size. Step-by-Step Solution: 1. The element a[0][0] has base address 1002. Because each int is 2 bytes, a pointer to the next element in the row will have address 1002 + 2 = 1004. 2. The expression a[0] is a pointer to a[0][0], so a[0] has the value 1002 when printed as an address. 3. The expression a[0] + 1 performs pointer arithmetic: it moves one int forward, adding 2 bytes. Thus a[0] + 1 has address 1004. 4. The expression *(a[0] + 1) dereferences the pointer a[0] + 1. That pointer refers to a[0][1], whose value from the initialiser list is 2. 5. The expression *(a + 0) is the same as a[0]; it is the pointer to the first element in the first row. 6. Therefore *( *(a + 0) + 1 ) is again equivalent to *(a[0] + 1), which is the value 2 stored at a[0][1]. 7. Putting it all together, printf prints the three values: address 1004, the value 2, and the value 2, separated by spaces. Verification / Alternative check: You can verify the address arithmetic by writing a simplified program that prints &a[0][0] and &a[0][1] using %p and comparing the difference. On a system where sizeof(int) is 2 bytes and the addresses start at 1002 for the sake of the example, the second address will be 1004. You can also confirm that a[0][1] always stores 2 by printing that element directly with printf("%d", a[0][1]);. These independent checks align with the pointer expressions used in the question and support the final result of 1004 2 2. Why Other Options Are Wrong: Option B, 1002 2 2, assumes that a[0] and a[0] + 1 point to the same address, which contradicts pointer arithmetic rules. Option C, 1004 3 3, incorrectly assumes that the value after the first element is 3 rather than 2, ignoring the actual initialiser. Option D, 1002 1 1, incorrectly uses the base address and the first element value for all three outputs. Only option A correctly reflects the address offset of 2 bytes and the repeated value 2 from the second element in the first row. Common Pitfalls: A common mistake is to think that incrementing a pointer by 1 adds one byte rather than one element size. Another frequent confusion is mixing up the role of a, a[0], and &a[0][0]. Learners sometimes also forget that in row major order, the first row is contiguous in memory, so a[0][0], a[0][1], a[0][2], and a[0][3] are consecutive elements. This question reinforces a careful step by step approach: identify the base element, use the correct element size, compute pointer arithmetic, and then dereference to obtain values. Final Answer: Given the base address 1002 and an int size of 2 bytes, the program prints 1004 2 2.

Question 18

In a C program that uses POSIX threads on a Unix or Linux system, you see the linker error message "undefined reference to pthread_create". What is the correct way to fix this build error?

Accepted Answer

Introduction / Context: When working with POSIX threads in C on Unix or Linux systems, developers must both include the proper header files and link against the correct libraries. The error message undefined reference to pthread_create is a classic linker error that indicates the compiler found the declaration of pthread_create but the linker could not find its implementation in any linked library. This question checks whether the learner knows how to correctly link a program that uses the POSIX threads API. Given Data / Assumptions: - The source code calls pthread_create to create a new thread. - The programmer is compiling on a Unix or Linux system where POSIX threads are available. - The compiler shows a linker error undefined reference to pthread_create at link time, not a compile time syntax error. - The appropriate header is assumed to be included, or can easily be included, so the remaining issue is at the linking stage. Concept / Approach: In C toolchains on Unix like systems, compilation and linking are separate steps. Header files provide declarations so that the compiler knows the function signatures, while libraries provide the actual compiled code that the linker connects to. The pthread library is usually not linked by default and must be specified explicitly using compiler options such as -pthread or -lpthread. The -pthread option also sets appropriate thread related flags for compilation, whereas -lpthread links specifically against the pthread library. Understanding the difference between including headers and linking libraries is essential for resolving this kind of error. Step-by-Step Solution: 1. Confirm that the code includes the header so that the compiler knows the declaration of pthread_create. 2. Observe the error undefined reference to pthread_create, which occurs at the linking stage, indicating that the symbol is not being found in the linked libraries. 3. Recognise that the POSIX thread functions are implemented in the separate pthread library. 4. Adjust the build command so that the compiler driver invokes the linker with -pthread, for example: gcc main.c -pthread -o myprog. 5. Alternatively, on some toolchains, you can compile with gcc main.c -o myprog -lpthread, which explicitly links that library. 6. Rebuild the program with the corrected command and verify that the linker error disappears and the binary is produced successfully. Verification / Alternative check: You can verify the fix by running two builds. First, compile with a plain command such as gcc main.c -o myprog; you should see the undefined reference error if pthread_create is used. Next, compile with gcc main.c -pthread -o myprog; this time the linker should succeed. Running the resulting program should show that threads are created correctly. On some platforms, using -lpthread instead of -pthread may work, but -pthread is usually preferred because it also sets thread safe compilation flags. Why Other Options Are Wrong: Option B is incorrect because does not declare pthread_create; that declaration is in . Option C is wrong because enabling warnings and treating them as errors does not cause the linker to automatically locate missing libraries; it only affects diagnostics. Option D suggests replacing pthread_create with fork, which fundamentally changes the model from multithreading to multiprocessing and does not resolve the original need for thread creation. Only option A correctly states that you must link with the POSIX threads library using -pthread or -lpthread. Common Pitfalls: A common mistake is to assume that including the correct header is sufficient and to forget that libraries must be specified independently when linking. Another pitfall is placing -lpthread before object files on command lines where linkers require libraries to appear after the objects that reference them. Developers also sometimes confuse compilation errors (related to syntax or missing declarations) with linker errors (related to missing symbol definitions). This question helps clarify these distinctions and reinforces the correct build flags for threaded programs. Final Answer: To fix the undefined reference to pthread_create error, you must link against the POSIX threads library, for example using gcc source.c -pthread -o program or a similar command with the -pthread or -lpthread option.

Question 19

In HTML, which tag is used to create drop-down list boxes and scrolling list boxes in a web form?

Accepted Answer

Introduction / Context: HTML forms provide various controls for user input, including text fields, check boxes, radio buttons, and list boxes. Drop down list boxes and scrolling list boxes are commonly used when a user must choose from a predefined set of options. This question tests basic HTML knowledge by asking which tag is responsible for constructing these list type controls in a form. Given Data / Assumptions: - The question refers specifically to drop down list boxes and scrolling list boxes used in HTML forms. - We assume a standard HTML environment in modern browsers. - The focus is on the markup tag that defines the list element itself, not on the broader form element or individual option entries alone. Concept / Approach: In HTML, drop down and list style controls are created using the select element. The select tag defines the list control, while nested option elements define the individual selectable items. When the size attribute of select is 1, most browsers display a drop down list. When size is greater than 1, the browser typically shows a scrolling list box. The name attribute of select is used to send the selected value back to the server during form submission. Step-by-Step Solution: 1. Recall that a typical HTML drop down is written as tag. 2. The tag select indicates to the browser that this element is a list control that can be rendered as a drop down or scroll box. 3. Inside the select element, each option tag represents a single choice the user can select. 4. There is no standard tag called in HTML, and is not the correct syntax for creating select style controls. 5. Therefore, the correct answer is the select tag, which is the core markup for both drop down and scrolling list boxes. Verification / Alternative check: An example snippet confirms this: . Testing this HTML in a browser shows a drop down list. Changing or adding the size attribute, such as , is not standard HTML syntax for creating list boxes. The input element supports various types like text, checkbox, radio, and so on, but list boxes are not created this way. Option C,

Programming Questions