Question 1

In the following C program that uses a do-while loop, how many times is the value of i checked in the loop condition?  #include <stdio.h> int main() {     int i = 0;     do     {         i++;         printf("In while loop\ ");     } while (i < 3);  …

Accepted Answer

Introduction / Context: This question tests your understanding of the control flow of a do-while loop in C, especially how many times the loop condition is evaluated. Unlike a while loop, a do-while loop always executes its body at least once and then checks the condition at the end of each iteration. Given Data / Assumptions: • The variable i is initialized to 0. • The loop body increments i and prints a message. • The condition is i < 3 and is checked at the end of each loop execution. • The question asks specifically how many times the value of i is checked in the while condition, not how many times the body executes. Concept / Approach: In a do-while loop, execution always follows this pattern: execute the body once, then check the condition; if the condition is true, execute the body again, then check the condition again; and so on until the condition becomes false. The number of condition checks is equal to the number of completed iterations. For a loop that runs a fixed number of times, we can simulate the iterations and count the checks. Step-by-Step Solution: Step 1: Before the loop starts, i = 0. Step 2: First iteration: execute the body, i++ makes i = 1, print "In while loop". Then check the condition i < 3: this is the first condition check (1 < 3 is true). Step 3: Second iteration: body runs again, i++ makes i = 2, print "In while loop". Check the condition again: second condition check (2 < 3 is true). Step 4: Third iteration: body runs again, i++ makes i = 3, print "In while loop". Check the condition once more: third condition check (3 < 3 is false). Step 5: Because the third check is false, the loop terminates and the condition is not evaluated again. Verification / Alternative check: Notice that the loop body executed three times and after each execution the condition was evaluated once, totaling three checks. Another way to see it is that for a do-while loop that runs N times, the condition will be checked N times: once after each completed iteration. Since i takes on values 1, 2 and 3 inside the loop and stops when i becomes 3 and fails the condition, N is 3 and so the condition is checked three times. Why Other Options Are Wrong: Option A (2) would imply that the loop condition is only evaluated twice, which would stop the loop earlier than actually happens. Option C (4) would mean a fourth condition check occurs, but once the condition is false on the third check, the loop exits and no further checks are made. Option D (1) is clearly too small because the loop runs several times and must check the condition after each iteration. Common Pitfalls: A common mistake is to confuse the number of times the loop body executes with the number of times the condition is checked in pre-test loops like while. In do-while loops, it is easy to forget that the body executes before the first condition check. Some learners also incorrectly assume there is an extra check before entering the loop, but that applies to while, not do-while. Carefully simulating the loop with a small table of i values and checks helps avoid these off by one errors. Final Answer: The condition i < 3 is evaluated after each of the three iterations, so the value of i is checked 3 times.

Question 2

In the following C program, what will be printed for the sizes of the pointer variables better and best (assume a 32-bit system)?  #include <stdio.h> void main() {     char good, *better, *best;     printf("%d..%d", sizeof(better), sizeof(best)); }

Accepted Answer

Introduction / Context: This question focuses on how the sizeof operator behaves with pointers in C. It is important to understand that the size of a pointer type depends on the machine architecture (for example, 32-bit or 64-bit), not on the type of data it points to. Here we explicitly assume a 32-bit system where pointers are typically 4 bytes wide. Given Data / Assumptions: • good is a variable of type char. • better and best are variables of type char * (pointers to char). • The program prints sizeof(better) and sizeof(best) using "%d..%d". • We assume a 32-bit platform where all data pointers are 4 bytes. • The computation does not depend on the value stored in the pointers. Concept / Approach: In C, sizeof applied to a pointer variable gives the size of the pointer itself, not the size of the object it points to. On a 32-bit system, a typical data pointer (such as char *, int * or double *) occupies 4 bytes, regardless of the pointee type. Therefore sizeof(better) and sizeof(best) both yield 4. The printed output combines these two integers with two dots between them. Step-by-Step Solution: Step 1: better is declared as char *better;, so it is a pointer variable storing an address. Step 2: best is declared as char *best; and is also a pointer variable storing an address. Step 3: On a 32-bit system, the size of any data pointer is typically 4 bytes, so sizeof(better) = 4 and sizeof(best) = 4. Step 4: The printf call prints these sizes with the format "%d..%d", so the exact output becomes 4..4. Step 5: There is no dependency on the values stored in good, better or best; only their types matter for sizeof. Verification / Alternative check: If you changed the declarations to int *p; double *q; and printed sizeof(p) and sizeof(q) on the same 32-bit system, you would still get 4..4. This confirms that pointer size is determined by the architecture, not by the type pointed to. On a 64-bit system, you might instead see 8..8, but the question fixes the assumption to a 32-bit platform, leading to 4..4. Why Other Options Are Wrong: Option A (1..2) incorrectly suggests that pointer size depends on the underlying data type or that they differ in width, which is not true for standard data pointers on a 32-bit system. Option C (4..2) mixes two different sizes without justification. Option D (2..2) reflects an older 16-bit environment where pointers could be 2 bytes, but this contradicts the more common 32-bit assumption used in such exam questions. Common Pitfalls: A common mistake is to confuse sizeof(pointer) with sizeof(*pointer). The former gives the size of the pointer itself, while the latter gives the size of the pointee type (for example, sizeof(*better) would be 1 because it is a char). Another pitfall is assuming that pointer size changes with the pointee type, which is usually not the case on mainstream architectures. Always remember to consider the platform word size when reasoning about pointer sizes in interview or exam questions. Final Answer: On a 32-bit system, both char pointers occupy 4 bytes, so the program prints 4..4.

Question 3

In the following C program that uses a goto label defined in a different function, what happens when you try to compile it?  #include <stdio.h>  void fun(void) { here:     printf("PP"); }  int main(void) {     int i = 1;     while (i <= 5)     {    …

Accepted Answer

Introduction / Context: This question examines your understanding of the rules governing goto statements and labels in C. While goto can be used for jumps within a function, it has strict limitations. One of the most important is that a goto cannot jump to a label that is defined in a different function. Violating this rule leads to a compile time error. Given Data / Assumptions: • The label here: is defined inside the function fun. • The goto here; statement is used inside main. • Both functions are defined in the same translation unit but are distinct functions. • The code is otherwise assumed to use correct syntax. Concept / Approach: In C, labels used by goto are local to the function in which they are defined. This means a goto inside one function may only target labels within the same function body. Jumping into another function, up the call stack or into a different scope in an illegal way is not allowed. The compiler enforces this by rejecting code where a goto label cannot be resolved in the current function. Step-by-Step Solution: Step 1: Identify the label declaration: here: appears inside fun, making it local to fun. Step 2: Observe the goto statement in main: goto here; appears in a different function, main. Step 3: The C standard specifies that labels have function scope only and cannot be referenced from another function. Step 4: When the compiler processes main, it cannot associate the label here with any label declared in main, so it reports an error. Step 5: Because of this, the program fails to compile and never runs, so it does not produce any runtime output or exceptions. Verification / Alternative check: If you move the label here: into main, for example placing it before printf("PP") in a block within main, then goto here; would become valid as long as it does not violate other rules such as jumping into a different block with initialized variables. The fact that this modification makes the program compile confirms that the issue in the original code is the cross function jump, not the use of goto itself. Why Other Options Are Wrong: Option A ("1") and Option B ("2") suggest that the program compiles and runs, printing some limited output, which is impossible because compilation fails first. Option D ("Exception occurs at runtime") is also incorrect, as the program never reaches runtime due to the compile time violation of the goto rules. The only correct characterization is that the compiler rejects the code because the label is not in the same function as the goto. Common Pitfalls: A common misunderstanding is to think of goto as a general jump mechanism like in assembly, capable of jumping across functions and arbitrary addresses. In C, goto is much more restricted and is only meant for local jumps within a function. Another pitfall is forgetting that labels have function scope, not file scope. Overusing goto can also lead to unstructured code, which is why structured control constructs (if, while, for) are generally preferred, but even when goto is used, it must respect these scoping rules. Final Answer: Because the goto attempts to jump to a label in another function, the program does not compile and produces a compilation error.

Question 4

In an object oriented language such as Java or C#, for a declaration and call like x = Circle(), which statement about x is most accurate?

Accepted Answer

Introduction / Context: This question tests your conceptual understanding of how objects are represented in typical object oriented languages such as Java and C#. In these languages, variables that hold objects of user defined classes usually store references to those objects rather than the objects themselves being copied around by value. Given Data / Assumptions: • Circle is assumed to be a user defined class type. • The expression Circle() represents a constructor call that creates a new Circle object. • x is a variable that can hold the result of Circle(). • We are considering mainstream OO languages like Java or C#, not C++ value semantics. Concept / Approach: In Java and C#, class types are reference types. When you call a constructor such as new Circle() in Java or just Circle() in some pseudocode, the runtime allocates a Circle instance on the heap and returns a reference (a handle or pointer like value) to it. The variable x then stores that reference, not the object state itself. The distinction is important for understanding assignment, parameter passing and equality comparisons in OO programs. Step-by-Step Solution: Step 1: Interpret Circle() as constructing a new Circle instance, allocating memory and initializing its fields. Step 2: Recognize that in Java and C#, the result of such a constructor call is a reference to the newly created object, not a raw integer or a copy by value. Step 3: The variable x, when declared with a compatible type like Circle x; and then assigned x = new Circle();, stores that reference. Step 4: When x is passed to methods or assigned to other variables, the reference is copied, not the entire object. Step 5: Therefore, the most accurate statement is that x contains a reference to a Circle object created by Circle(). Verification / Alternative check: Consider two variables x and y where both are assigned the same Circle() result, or y = x after x has been initialized. Modifying the circle's radius through y would also be visible when accessed through x, which only happens if both variables refer to the same underlying object by reference. If x contained the full object by value, such sharing would not occur. This behavior matches the reference semantics described in the correct option. Why Other Options Are Wrong: Option B is wrong because assigning an int directly to x makes sense only if x is of an integral type, which contradicts the notion that Circle() returns an object reference. Option C incorrectly claims that x contains a complete object stored by value on the stack in all OO languages; that might be true in certain C++ scenarios with automatic storage, but it is not generally true for class types in Java and C#. Option D is wrong because x is not just an int radius; it represents the entire Circle object or more precisely a reference to it. Common Pitfalls: A common pitfall is to confuse reference types and value types. In some languages, structs or primitive types like int are value types, but classes like Circle are reference types. Another frequent confusion occurs when comparing objects using ==, which in many languages compares references rather than object contents. Remembering that variables of class type usually hold references helps clarify behavior when assigning, passing and comparing objects. Final Answer: In a typical OO language, x contains a reference to a Circle object created by the call Circle().

Question 5

In C programming, what is the output of this code that evaluates an expression with the modulus, multiplication and division operators?  #include <stdio.h> void main() {     int y = 3;     int x = 5 % 2 * 3 / 2;     printf("Value of x is %d", x); }

Accepted Answer

Introduction / Context: This question tests your understanding of operator precedence and associativity in C, particularly for the modulus (%), multiplication (*) and division (/) operators. All three have the same precedence and are evaluated left to right. The result is then printed using printf. Given Data / Assumptions: • The expression assigned to x is 5 % 2 * 3 / 2. • All operands are integers, so integer arithmetic is used. • The variable y is unused and does not affect x. • printf prints x with the format "Value of x is %d". Concept / Approach: Since %, * and / share the same precedence level in C, the expression is evaluated strictly from left to right. Each intermediate result is an integer, and division truncates toward zero. We can break the compound expression into sequential steps, computing two operands at a time, then using the result in the next operation. Carefully following this evaluation order yields the final integer value stored in x. Step-by-Step Solution: Step 1: Start with 5 % 2 * 3 / 2. Because of left to right associativity, compute 5 % 2 first. Step 2: 5 % 2 is the remainder when 5 is divided by 2, which is 1. Step 3: The expression now becomes 1 * 3 / 2. Step 4: Next, compute 1 * 3, still following left to right order. That gives 3. Step 5: The expression is now 3 / 2. As integer division, 3 / 2 is 1 because the fractional part 0.5 is discarded. Step 6: Thus x is assigned the value 1. printf prints "Value of x is 1". Verification / Alternative check: You can confirm this result by quickly rewriting the expression with parentheses that reflect left to right associativity: ((5 % 2) * 3) / 2. Evaluating this form step by step clearly shows the same sequence: (5 % 2) = 1, then 1 * 3 = 3, then 3 / 2 = 1. This matches the earlier reasoning and confirms that any different result comes from misapplying precedence or treating division as floating point instead of integer. Why Other Options Are Wrong: Option B ("Value of x is 2") might come from mistakenly computing 3 / 2 as 1.5 and then rounding up, which is not how integer division behaves. Option C ("Value of x is 3") would be correct if the final division by 2 were forgotten, leaving x = 3. Option D ("Compile time error") is wrong because the expression is perfectly valid C, and unused variable y does not cause a compilation failure. Common Pitfalls: A common error is to assume that division of integers yields a floating point result, but in C the type of the operands controls the result type; integer division discards any fractional part. Another pitfall is misunderstanding precedence and associativity, for example trying to apply multiplication before modulus or incorrectly grouping operations. Remember that % has the same precedence as * and /, and all three associate from left to right, so evaluating them sequentially is the safest mental model. Final Answer: After evaluating 5 % 2 * 3 / 2 from left to right, the program prints "Value of x is 1".

Question 6

In C programming, what is the output of this code that uses the left shift operator on an integer?  #include <stdio.h> void main() {     int x = 1, z = 3;     int y = x << 3;     printf("%d\ ", y); }

Accepted Answer

Introduction / Context: This question checks your understanding of the bitwise left shift operator in C. Shifting an integer left by n positions is equivalent to multiplying it by 2^n, provided there is no overflow and the value remains within the valid range of the type. Given Data / Assumptions: • x is initialized to 1. • z is initialized to 3 but is not used in the computation of y. • y is assigned x << 3. • printf prints y as a decimal integer. • We assume a typical two's complement representation and that the result does not overflow int. Concept / Approach: The expression x << 3 shifts the bits of x three positions to the left. For positive integers that fit in the type, each left shift by one multiplies the value by 2. Therefore, shifting left by 3 multiplies the value by 2^3 = 8. Starting from x = 1, the result y should be 1 * 8 = 8, which is well within the range of int and causes no overflow. Step-by-Step Solution: Step 1: Write x in binary: 1 is 0001 in simplified 4-bit notation (and similar in larger width). Step 2: Shift left by 1 position: 0001 becomes 0010, which is 2 in decimal. Step 3: Shift left by another position: 0010 becomes 0100, which is 4 in decimal. Step 4: Shift left by a third position: 0100 becomes 1000, which is 8 in decimal. Step 5: Therefore x << 3 evaluates to 8, so y = 8 and printf prints 8 followed by a newline. Verification / Alternative check: Using the multiplication view, each left shift multiplies the value by 2, so x << 3 is x * 2^3 = 1 * 8 = 8. This matches the bitwise reasoning and confirms that the result is 8. Because 8 is a small positive integer, there is no risk of exceeding int's capacity on any realistic platform, so we do not need to consider overflow scenarios here. Why Other Options Are Wrong: Option A (-2147483648) might be associated with overflow scenarios in 32-bit two's complement int, but there is no overflow when shifting 1 by three bits. Option B (-1) could appear in questions about right shift of negative numbers, but here we are left shifting a positive number. Option C ("Run time error") is incorrect; bitwise shifts on valid operands do not cause runtime errors by themselves in this simple context. Common Pitfalls: One pitfall is confusing left shift << with right shift >>, which behaves differently, especially for signed negative values. Another common mistake is forgetting that shifting too far can cause undefined behavior or overflow, but in this case the shift is small and safe. Also, some learners misinterpret the presence of an unused variable (z) as relevant to the answer; in fact, it has no effect on y or the output at all. Final Answer: The value of y is 1 << 3 = 8, so the program prints 8.

Question 7

In the following C program, what happens when you attempt to modify a const int object through a non const pointer?  #include <stdio.h> int main(void) {     const int x = 5;     int *ptrx;     ptrx = &x; /* attempt to assign address of const int to …

Accepted Answer

Introduction / Context: This question examines const correctness in C and what happens when you try to circumvent const by using a non const pointer. It focuses on the type system rather than the exact runtime behavior, highlighting that assigning the address of a const object to a non const pointer is a constraint violation that the compiler must diagnose. Given Data / Assumptions: • x is declared as const int x = 5; which means its value must not be modified through a const correct interface. • ptrx is declared as int *ptrx; a pointer to non const int. • The assignment ptrx = &x; attempts to store the address of x in a non const pointer. • The code then writes *ptrx = 10; and prints x. • We assume a standards compliant C compiler that enforces const correctness. Concept / Approach: In C, the type of &x is const int *. Assigning a const int * to an int * without an explicit cast is not allowed; it discards qualifiers and violates type safety. The C standard requires that such an assignment be diagnosed as a constraint violation. Therefore, the program is ill formed and should produce at least a warning or an error, typically preventing successful compilation if treated strictly. Although some compilers may still generate code and lead to undefined behavior at runtime, the correct conceptual answer in an exam context is that this is an error. Step-by-Step Solution: Step 1: Determine the type of &x: because x is const int, &x has type const int *. Step 2: Determine the type of ptrx: it is int *, a pointer that can legally modify the int it points to. Step 3: The assignment ptrx = &x; attempts to convert const int * to int *, discarding the const qualifier. Step 4: This kind of assignment is forbidden in standard C; the compiler must issue a diagnostic. Step 5: Because of this type mismatch, the program should be considered as having an error and not relied upon to compile or run correctly. Verification / Alternative check: If you correct the code to use const int *ptrx = &x; then *ptrx = 10; would also be rejected because it tries to write through a pointer to const. This demonstrates that the language intends x to be read only after being declared const. Any attempt to bypass this by discarding const qualifiers is treated as undefined or erroneous. Compilers that enforce warnings as errors will refuse to compile the original code, confirming that "Error" is the safest and most standard conforming interpretation. Why Other Options Are Wrong: Option A ("5") assumes that the attempt to modify x is ignored and the original value is always printed, which is not guaranteed; the behavior is undefined if the code is forced to run. Option B ("10") assumes that the modification always succeeds, which again is not guaranteed and depends on implementation details. Option D ("A random garbage value") suggests runtime undefined behavior, but the key exam point is that the code is already in error at the type system level; the primary correct answer focuses on the compile time issue. Common Pitfalls: Many learners think of const as merely an advisory keyword that can be bypassed without consequences. In reality, const is part of the type, and discarding it in pointer conversions violates constraints. Another pitfall is focusing only on the printf output instead of noticing the const mismatch earlier in the code. When analyzing code, always check pointer types and qualifier correctness before reasoning about runtime results, as type errors can invalidate any assumptions about output. Final Answer: Because the code assigns the address of a const int to a non const pointer and then writes through it, the correct conceptual answer is that it results in an error due to const mismatch.

Question 8

In the following C program using a const pointer to char, where does the error occur and why?  #include <stdio.h> int main(void) {     char mybuf[] = "Zanzibar";     char yourbuf[] = " Zienckewiz";     char * const ptr = mybuf;     *ptr = 'a';     p…

Accepted Answer

Introduction / Context: This question explores the meaning of a const pointer declaration in C: char * const ptr. It checks whether you can distinguish between a constant pointer (whose address value cannot change) and a pointer to const data (whose pointed to data cannot change). Correctly interpreting which part is const is crucial for understanding which operations are allowed. Given Data / Assumptions: • mybuf and yourbuf are character arrays initialized from string literals. • ptr is declared as char * const ptr = mybuf; which means ptr is a constant pointer to non const char. • The statement *ptr = 'a'; attempts to modify the first character in mybuf through ptr. • The statement ptr = yourbuf; attempts to change ptr so it points to a different array. • The code is otherwise syntactically correct. Concept / Approach: The declaration char * const ptr means: "ptr is a constant pointer to char". The const applies to the pointer itself, not to the data. So ptr must always point to the same address after initialization, but the characters at that address are modifiable because they are not declared const. Therefore writing through *ptr is allowed, but reassigning ptr to a new address is not. Step-by-Step Solution: Step 1: Interpret char * const ptr = mybuf; as making ptr a constant pointer that initially points to mybuf[0]. Step 2: Since the pointee type is plain char (not const char), modifying *ptr is equivalent to modifying mybuf[0], which is legal because mybuf is a modifiable array. Step 3: The statement *ptr = 'a'; simply changes the first character of mybuf from 'Z' to 'a', which is allowed. Step 4: The next statement ptr = yourbuf; attempts to change the pointer value so that ptr no longer points to mybuf but to yourbuf. Step 5: Because ptr is declared const, its value (the stored address) cannot be changed after initialization, so this assignment violates the constness of ptr and causes a compilation error. Verification / Alternative check: You can rewrite the declaration as char * const ptr and contrast it with const char *ptr. In the latter case, the data is const but the pointer itself is not, so ptr can point to different strings but you cannot change the characters through ptr. In this question, the const is placed after the *, which means the pointer is const. This confirms that the illegal operation is reassigning ptr, not modifying the character it points to. Why Other Options Are Wrong: Option A is wrong because there is indeed an error: ptr = yourbuf; is not allowed. Option B is wrong because *ptr = 'a' is valid; the character data is not const, only the pointer is. Option D is wrong because the array initializations are fine: mybuf and yourbuf are local arrays initialized with string literals, which is standard and legal. Common Pitfalls: A frequent confusion arises between "pointer to const" and "const pointer". Remember the rule: const placed to the left of * usually applies to the pointed to data (const char *), while const placed to the right of * usually applies to the pointer itself (char * const). Additionally, some learners mistakenly think anything involving const forbids all modifications; in reality you must be precise about which entity is const. Understanding these distinctions improves your ability to read and write const correct interfaces. Final Answer: The illegal action is reassigning the const pointer, so the error occurs at ptr = yourbuf; because you cannot change the value of a const pointer variable.

Question 9

In C programming, what operations are performed by the library style functions atoi(), itoa() and gcvt() when converting between strings and numeric values?

Accepted Answer

Introduction / Context: This question focuses on common C style conversion functions that move data between string form and numeric form. Understanding what atoi(), itoa() and gcvt() do helps you parse numeric input and format numeric output without always relying on scanf and printf. Although not all of these functions are part of the ISO C standard (itoa() and gcvt() are often extensions), they are widely used in many environments and appear frequently in exam questions. Given Data / Assumptions: • atoi() takes a string (char *) argument. • itoa() typically takes an integer, a buffer and a base. • gcvt() typically takes a double value, a number of significant digits and a destination buffer. • The question asks what conversion each function performs. • We assume typical implementations such as those in standard libraries or common compilers. Concept / Approach: The name atoi stands for "ASCII to int" and converts a numeric string to an integer value. The name itoa stands for "int to ASCII" and converts an integer into its string representation in a specified base (such as base 10 or 16). The function gcvt is often used to convert a floating point number (double) to a string with a given number of significant digits. Correctly pairing each function with its direction of conversion is the key to answering this question. Step-by-Step Solution: Step 1: For atoi(), recall that it parses characters in a string, skipping whitespace and reading optional sign and digits, returning an int value. Example: atoi("123") yields 123. Step 2: For itoa(), a typical prototype is char *itoa(int value, char *str, int base); it stores the textual representation of value in str using the given base, e.g., itoa(255, buf, 10) produces "255". Step 3: For gcvt(), a typical prototype is char *gcvt(double value, int ndigit, char *buf); it converts value into a string with ndigit significant digits, stored in buf, such as gcvt(3.14159, 4, buf) yielding something like "3.142". Step 4: Compare these behaviors with the options and select the one that accurately describes each function's role. Verification / Alternative check: To verify, you can write small examples: use atoi("42") and confirm that an int 42 is returned. Use itoa(42, buf, 10) and observe that buf contains "42". For gcvt(), pass a double such as 123.456 and request a few digits; the result in the buffer is a human readable decimal string. These quick experiments confirm the described directions of conversion, distinguishing them from any string case transformation or file I/O behavior. Why Other Options Are Wrong: Option B reverses the roles of atoi() and itoa(), claiming that atoi() converts int to string and itoa() does the opposite, which contradicts their names and behavior. It also incorrectly states that gcvt() converts a string to uppercase, which is unrelated to numeric conversion. Option C suggests all three perform generic file I/O, which is completely incorrect. Option D suggests that the functions are limited only to certain data structures (character arrays or structures), misrepresenting them; they are specifically about numeric to string and string to numeric conversions. Common Pitfalls: A common pitfall is to assume that all conversions should always use scanf/printf, ignoring these helper functions. Another mistake is mixing up the direction of conversion for functions whose names are easy to misremember. A helpful mnemonic is that the first letter indicates the source type: a in atoi means ASCII (string) to int, i in itoa means int to ASCII, and g in gcvt is often remembered in the context of "general" or "G format" style conversion for floating point numbers. Being clear on these directions avoids confusion in both exams and code. Final Answer: Correctly summarized, atoi() converts a string to int, itoa() converts an int to string and gcvt() converts a double or float to a string representation.

Question 10

In C and related environments, what is the difference in purpose between the functions rand(), random(), srand() and randomize() when working with pseudo random numbers?

Accepted Answer

Introduction / Context: Many C environments provide functions for generating pseudo random numbers and seeding the underlying random number generator. This question asks you to distinguish between rand(), random(), srand() and randomize(), which often appear together in textbooks and compilers such as Turbo C or Unix like systems. Understanding which functions generate numbers and which functions seed the generator is important for writing predictable or varied random behavior. Given Data / Assumptions: • rand() is part of the ISO C standard library (stdlib.h) and returns an int pseudo random value. • random() is a similar function provided on many Unix like systems, returning a pseudo random long int. • srand() is the standard function used to seed the rand() generator with a specific unsigned int value. • randomize() is a common nonstandard function in some older compilers that seeds the generator using a changing source like the system clock. • The question is about conceptual roles, not exact prototypes. Concept / Approach: Conceptually, two of these functions are used to generate pseudo random integers (rand() and random()) and two are used to initialize or seed the generator (srand() and randomize()). Seeding with a fixed value makes sequences reproducible, while seeding with a time based or environment dependent value makes sequences vary from run to run. Recognizing this separation between generator and seeding functions is the key to answering the question correctly. Step-by-Step Solution: Step 1: rand() returns an int in the range 0 to RAND_MAX, producing a pseudo random sequence based on an internal state. Step 2: random(), in environments that support it, similarly returns a pseudo random long int with some implementation defined range and is often considered higher quality than rand(). Step 3: srand(unsigned int seed) initializes or reinitializes the state used by rand(); calling srand() with the same seed causes rand() to produce the same sequence of values each time. Step 4: randomize(), in some nonstandard libraries, is a convenience function that seeds the random number generator with a value derived from the system clock or other changing source, so that sequences differ between program runs. Step 5: Grouping these facts, rand() and random() are generators, while srand() and randomize() are seed initializers, matching option A. Verification / Alternative check: You can test this behavior by writing a small program that calls srand(10); followed by several rand() calls, then running it multiple times. You will see the same sequence of numbers each run. If you instead call randomize() (in an environment that supports it), you will usually see different sequences each run, because the seed comes from the current time. On Unix systems, calling srandom(time(NULL)); plays a similar role for random(). These experiments match the conceptual roles assigned in the correct option. Why Other Options Are Wrong: Option B is clearly incorrect because none of these functions are file I/O, memory clearing or screen formatting functions. Option C is wrong because rand() and srand() do not generate floating point numbers; they work with integers and seeding. Option D is wrong because the four functions are not identical: some generate numbers, others seed, and not all exist in every implementation. In particular, random() and randomize() are nonstandard and may not be available everywhere. Common Pitfalls: A common mistake is to forget to seed the random number generator, leading to the same sequence of pseudo random numbers on each run when using rand(). Another pitfall is to assume that different library functions necessarily provide better randomness without understanding their intended usage. Also, relying on nonstandard functions like randomize() can hurt portability, so it is better to use standard combinations such as srand(time(NULL)); and rand() when writing portable C programs. Final Answer: In summary, rand() and random() generate pseudo random numbers, whereas srand() seeds the generator with a specific value and randomize() seeds it using a varying source such as the system clock.

Question 11

In C programming, what will be the output when you execute the following code that mixes switch case labels with goto?  #include <stdio.h> void main() {     switch (2)     {         case 1L:             printf("No");         case 2L:             pri…

Accepted Answer

Introduction / Context: This question tests your understanding of switch statement behavior, fall through between cases and the use of a goto label placed inside the switch in C. It requires careful tracing of control flow from the matching case label through the goto and subsequent statements. Given Data / Assumptions: • The switch expression is switch (2), so the case that matches is case 2L. • There are no break statements before or after the label Love: inside case 4L. • The label Love: is defined after case 4L but can be jumped to from case 2L. • We assume the code compiles as valid C with the proper stdio.h include. Concept / Approach: When switch (2) executes, control transfers directly to the matching case label case 2L. From there, execution continues sequentially unless a break, return or goto directs control elsewhere. In this code, the case 2L block prints "I" and then executes goto Love;, which jumps to the label Love: defined under case 4L. Execution resumes at that label and prints "Hi". There are no further statements in the switch, so execution then falls out of the switch and the function ends. Step-by-Step Solution: Step 1: Evaluate the switch expression: it is the constant 2. Step 2: The matching case label is case 2L:, so execution starts at printf("%s", "I"); within that case. Step 3: printf("%s", "I"); prints the character I. Step 4: Next, goto Love; transfers control to the label Love: defined under case 4L. Step 5: At Love:, the statement printf("Hi"); executes, printing Hi immediately after the already printed I. Step 6: After printing Hi, there are no more statements in the switch, so control falls out of the switch and the function terminates. The total output is IHi with no spaces or newlines. Verification / Alternative check: You can conceptually rewrite the relevant part: for the chosen switch value 2, the only reachable code is the body of case 2L and any code reached from it by goto. Although case 4L appears later, the goto jumps directly to the label inside it, then execution continues downward. No break statement is encountered before exiting the switch. There are no instructions that would print "Please" or "No" in this path, confirming the output is exactly IHi. Why Other Options Are Wrong: Option A ("I") ignores the fact that the goto leads to Love: where "Hi" is printed as well. Option B ("IPleaseHi") would be correct if execution flowed through case 3L and printed "Please", but the goto jumps directly to Love: inside case 4L, skipping printf("Please"). Option D ("Compilation error") is incorrect because using goto within a switch to a label inside the same function is legal C, provided the control flow does not violate restrictions such as jumping into a scope with uninitialized variables (which it does not here). Common Pitfalls: A common mistake is to assume that each case must end with break and that execution cannot jump into the middle of another case using goto. While using goto inside switch often leads to confusing code and is discouraged stylistically, it is permitted as long as label scoping rules are respected. Another pitfall is to expect automatic breaks after each case, but in C fall through is allowed and often exploited, so you must carefully track where control goes and where it can be diverted by jumps. Final Answer: The program prints "I" in case 2L and then jumps to Love:, where it prints "Hi", so the combined output is IHi.

Question 12

In algorithm design, which of the following best describes what a simple linear search function written in C does when searching an array for a target value?

Accepted Answer

Introduction / Context: Linear search is one of the simplest and most fundamental search algorithms. It is often the first search technique implemented by students when learning C programming. Understanding how linear search works conceptually prepares you to write the corresponding C function and to compare it with more advanced algorithms like binary search. Given Data / Assumptions: • We are discussing a typical linear search implemented over an array in C. • The algorithm receives an array, its length and a target value to search for. • The array is not assumed to be sorted. • The question asks which description best matches the behavior of linear search. Concept / Approach: A linear search (also called sequential search) checks elements one by one in sequence. Starting from index 0, it compares each element with the target. If it finds an element equal to the target, it usually returns the index or a success flag. If it reaches the end of the array without finding the target, it reports failure. This behavior is very different from binary search, which requires sorted data and repeatedly halves the search interval. Step-by-Step Solution: Step 1: Initialize an index i to 0. Step 2: While i is less than the array length, compare array[i] with the target value. Step 3: If array[i] equals the target, return i or indicate that the target is found and stop the search. Step 4: If array[i] does not equal the target, increment i and repeat the comparison for the next element. Step 5: If the loop completes without a match (i reaches the array length), return -1 or some special value indicating that the target is not present. Verification / Alternative check: To verify this description, consider searching for 7 in the array [3, 5, 7, 9]. A linear search would compare 3, then 5 and then 7, stopping as soon as it finds 7 at index 2. If you searched for 4 in the same array, the algorithm would compare 3, then 5, then 7, then 9 and finally conclude that 4 is not present after examining all elements. This matches the sequential, start to end scanning behavior described in the correct option. Why Other Options Are Wrong: Option B describes binary search, which divides the search interval in half and requires sorting the array first; this is not linear search. Option C is incorrect because no meaningful algorithm assumes the target is always in the middle; doing so would fail whenever the target is elsewhere or absent. Option D describes a heap based approach, which might be used for priority queues, not for a simple linear search over an unsorted array. Common Pitfalls: A common pitfall is to confuse linear and binary search because both are search algorithms. Remember that linear search does not require sorting and is O(n) in the worst case, whereas binary search requires a sorted array and runs in O(log n). Another pitfall is to forget to handle the "not found" case correctly in a C implementation, leading to returning an uninitialized index. Clearly understanding the conceptual behavior helps you implement the algorithm correctly and recognize it in multiple choice questions. Final Answer: A simple linear search in C scans each element from start to end, comparing it with the target until it either finds a match or reaches the end of the array.

Question 13

In C programming, rewrite the following set of statements using the conditional (ternary) operator so that the behavior is preserved:  int a = 1, b; if (a > 10)     b = 20;

Accepted Answer

Introduction / Context: This question tests understanding of the conditional (ternary) operator in C and how to rewrite a simple if statement in a compact but equivalent single expression. It also checks whether you pay attention to preserving the original program behavior, including the case where the if condition is not satisfied. Given Data / Assumptions: We have variables declared as int a = 1, b. There is an if statement: if (a > 10) b = 20; There is no explicit else part, so if a is not greater than 10, b should remain unchanged. We want to use the conditional (ternary) operator in place of the if statement. Concept / Approach: The conditional operator in C has the form condition ? expression1 : expression2. If condition is nonzero, expression1 is evaluated. Otherwise expression2 is evaluated. To preserve the semantics of the given if statement, we must assign 20 to b only when a is greater than 10 and leave the value of b unchanged otherwise. That means both sides of the colon need to produce a value for b, matching the original effect. Step-by-Step Solution: Identify the condition: a > 10. Identify the true branch effect: b should become 20. Identify the false branch effect: b should keep its previous value. Write a single assignment using the conditional operator: b = (a > 10) ? 20 : b; Check that when a is greater than 10, the expression yields 20, and when it is not, it yields the old value of b. Verification / Alternative check: If a is 15, the condition a > 10 is true, so the expression becomes b = 20; exactly like the original if statement. If a is 5, the condition is false, so the expression becomes b = b; which leaves b unchanged. No other side effects are introduced, so the rewritten code is behaviorally equivalent. Why Other Options Are Wrong: Option b uses a >= 10, which incorrectly includes the case a equals 10 and changes the behavior. Option c reverses the branches and assigns 20 when a is not greater than 10. Option d triggers assignment when a is less than 10, which is not what the original if statement does. Common Pitfalls: A common mistake is to forget the else part and write something like (a > 10) ? (b = 20) : 0; which is legal but less clear. Another error is to change the condition slightly, such as using a >= 10, which subtly changes the behavior. Always check that the false branch of the conditional leaves the variable unchanged when the original code had no else clause. Final Answer: The correct conditional operator form is b = (a > 10) ? 20 : b; which exactly matches the behavior of the original if statement.

Question 14

In C programming, consider the following recursive program:  main() {     printf("Jamboree");     main(); }  How many times will the word Jamboree be printed?

Accepted Answer

Introduction / Context: This question checks your understanding of recursion, function calls and program termination in C. It uses a deliberately simple but flawed recursive program where main calls itself without any stopping condition. You need to reason about what happens when a function keeps calling itself forever. Given Data / Assumptions: The function main calls printf with the string Jamboree and then calls main again. There is no base case and no return statement in the given code fragment. Each call to main is a normal function call that consumes stack space. We assume a typical hosted C environment with finite stack memory. Concept / Approach: In C, each function call allocates a new stack frame to store return addresses and local variables. When main calls main again without any condition, the recursion continues indefinitely at the language level. In practice the system stack is finite, so the recursion eventually exhausts available stack space, which leads to a runtime error such as stack overflow. Until that failure occurs, each call prints Jamboree exactly once. Step-by-Step Solution: The program starts in main and executes printf, which prints Jamboree. Immediately after printing, main calls main again, which repeats the same sequence. As long as the system can allocate new stack frames, each new invocation prints Jamboree and recurses again. There is no condition to stop the recursion and no return path that finishes the sequence normally. Eventually the runtime system runs out of stack space and terminates the program, but the exact number of prints depends on implementation details and is not fixed. Verification / Alternative check: On a real machine, if you run a similar program, you will see many repetitions of Jamboree printed to the console, followed by an abnormal termination such as a segmentation fault. There is no compilation error, because recursive calls to main are allowed by the language, even though they are a poor design choice. This confirms that the effect is repeated printing until failure, not a fixed number of outputs. Why Other Options Are Wrong: Printing exactly once or twice would require either a base case or logic that stops after a small number of recursive calls. The code does not contain a syntax error that prevents compilation, so it will compile in a typical C environment. Common Pitfalls: Some learners assume that main cannot be called recursively, which is not correct according to the C standard. Others forget about the stack limit and say that the word is printed infinitely many times. Conceptually the recursion is unbounded, but in practice the program terminates when resources are exhausted. For exam purposes, the intended answer is that it prints repeatedly until stack overflow or similar runtime failure. Final Answer: The program will print Jamboree repeatedly until it eventually crashes due to stack overflow or a similar runtime error, so there is no fixed finite count.

Question 15

In software design and documentation, a macro flowchart is also known as which type of flowchart?

Accepted Answer

Introduction / Context: Flowcharts are visual tools used to represent the logic and structure of systems and programs. Different levels of detail can be shown depending on the purpose of the diagram. A macro flowchart focuses on the overall structure rather than the fine details. This question checks whether you know the alternative name and typical role of a macro flowchart. Given Data / Assumptions: We are dealing with documentation and design diagrams for systems or programs. The term macro suggests something large scale or high level. The question asks for another commonly used name for a macro flowchart. The options distinguish between high level and detailed representations. Concept / Approach: A macro flowchart is intended to give an overview of the main processes, modules or phases in a system. It does not show individual statements or low level control structures. For that purpose, designers use detailed or micro flowcharts. Because it focuses on the big picture, a macro flowchart is often described as a high level or less detail flowchart, showing major steps and data flows without overwhelming detail. Step-by-Step Solution: Interpret the word macro as large scale or big picture, which suggests a summary view rather than detailed internals. Consider what kind of flowchart would use only major blocks such as input, process and output stages or high level modules. Recognize that such a diagram hides internal statement level complexity and therefore is a less detail representation. Compare this to micro or detailed flowcharts, which show decisions, loops and every important statement, which is not the intention of a macro flowchart. Select the option that explicitly mentions high level or less detail representation of the overall system structure. Verification / Alternative check: Many software engineering texts classify flowcharts into macro and micro forms. Macro flowcharts depict functional blocks of a system, sometimes spanning entire subsystems or programs. They are used in early design and communication with stakeholders. Micro flowcharts are introduced later to describe the internal logic of each module. This matches the description of a macro flowchart as high level or less detail. Why Other Options Are Wrong: A very detailed flowchart that shows every statement is the opposite of macro; it is closer to a micro or detailed flowchart. A simple detailed flowchart that expands every module is again a lower level diagram and not what macro refers to. Macro flowcharts are not restricted to hardware logic design; they are commonly used for software and business process modeling. Common Pitfalls: Learners sometimes assume that macro means complex or difficult, which can lead them to pick options that emphasize detail. In the context of documentation, macro refers to the scale of the view, not the complexity of the notation. Always remember that macro flowcharts summarize major steps, making them easier for nontechnical stakeholders to understand. Final Answer: A macro flowchart is also called a high level or less detail flowchart that shows only the major steps or modules of a system.

Question 16

Consider the following Java interface:  public abstract interface Frobnicate {     public void twiddle(String s); }  Which of the following Frob class declarations is correct with respect to this interface?

Accepted Answer

Introduction / Context: This question tests your knowledge of Java interfaces, abstract classes and method implementation rules. You are given an interface Frobnicate with a single method twiddle that takes a String parameter. You must determine which Frob class declaration is legal and consistent with Java interface implementation rules. Given Data / Assumptions: Interface Frobnicate declares public void twiddle(String s). Any concrete class that implements Frobnicate must provide a matching implementation of twiddle with a String parameter. An abstract class that implements an interface may leave some or all methods unimplemented, keeping them abstract. The options include different combinations of extends, implements and method signatures. Concept / Approach: In Java, interfaces are implemented using the implements keyword, not extends. A class that implements an interface must either provide concrete implementations of all interface methods or be declared abstract. If a class declares a method as abstract, it cannot provide a method body for that method. In addition, method signatures must match exactly, including parameter types, in order to fulfill an interface contract. Step-by-Step Solution: Check option a: it declares an abstract class and declares twiddle as abstract but also gives a method body, which is illegal in Java. An abstract method must not have a body. Check option b: it declares an abstract class that implements Frobnicate but does not define twiddle. This is legal, because abstract classes may leave interface methods abstract for subclasses to implement. Check option c: it tries to extend Frobnicate, which is wrong because Frobnicate is an interface and classes should implement interfaces, not extend them. Check option d: it declares a concrete class that implements Frobnicate but defines twiddle with an Integer parameter rather than a String parameter, which does not satisfy the interface method requirement. Conclude that option b is the only correct declaration. Verification / Alternative check: If you attempt to compile option b in a Java compiler, it will succeed, although any nonabstract subclass of Frob will need to implement twiddle. If you compile options a, c or d, the compiler will produce errors indicating either illegal abstract method syntax, incorrect use of extends or failure to implement the required method with the correct signature. Why Other Options Are Wrong: Option a mixes abstract with a method body, which Java does not allow. Option c misuses extends with an interface and defines the wrong method signature. Option d uses implements but also defines the wrong parameter type, so it does not actually implement twiddle as required. Common Pitfalls: Many learners confuse extends and implements when working with interfaces. Another common error is to change parameter types or method names slightly and assume that they still satisfy the interface contract. When implementing interfaces, always ensure that method names, parameter lists and return types match exactly, and remember that abstract classes can defer implementation to subclasses. Final Answer: The correct class declaration is public abstract class Frob implements Frobnicate { } which legally implements the interface while remaining abstract.

Question 17

In expression conversion, convert the following infix expression to its equivalent prefix notation:  ((A + B) * C – (D – E) ^ (F + G))

Accepted Answer

Introduction / Context: This question checks your understanding of operator precedence and associativity as well as your ability to convert an infix arithmetic expression to prefix notation. Prefix expressions place operators before their operands and remove the need for parentheses when precedence and associativity are handled correctly. Given Data / Assumptions: The given infix expression is ((A + B) * C – (D – E) ^ (F + G)). The operator precedence is assumed as follows: exponentiation has the highest precedence, then multiplication, then addition and subtraction. The caret symbol is used to denote exponentiation. Subtraction and addition are left associative, while exponentiation is usually treated as right associative. Concept / Approach: To convert an infix expression to prefix form, you can either construct an expression tree and then perform a preorder traversal, or use a stack based algorithm. The key is to respect operator precedence and explicit parentheses. The expression here can be grouped as (A + B) * C for the left part and (D – E) ^ (F + G) for the right part. The whole expression is then left part minus right part. Step-by-Step Solution: Start with the innermost parenthesized subexpressions: A + B and D – E and F + G. Convert A + B to prefix: + A B. Multiply this result by C, giving the infix group (A + B) * C, which in prefix is * (+ A B) C or * + A B C. For the right side, convert D – E to prefix: - D E, and F + G to prefix: + F G. Apply exponentiation on these two prefix expressions to get ^ - D E + F G. Finally, subtract the right side from the left side: (left) – (right) becomes prefix - (left) (right), which yields - * + A B C ^ - D E + F G. Verification / Alternative check: You can verify correctness by building a tree with the top node as minus, left child as the multiplication of (A + B) and C, and right child as exponentiation of (D – E) by (F + G). Performing a preorder traversal (visit root, then left subtree, then right subtree) produces the sequence - * + A B C ^ - D E + F G. None of the other options correspond to this tree structure. Why Other Options Are Wrong: Option b incorrectly makes multiplication the outermost operator and does not respect the top level subtraction. Option c incorrectly places the subtraction around addition and multiplication in the wrong order. Option d places exponentiation at the top, which does not match the original top level minus in the infix expression. Common Pitfalls: Learners often confuse the order in which to apply operators when converting complex expressions. Forgetting to group subexpressions correctly or ignoring operator precedence leads to incorrect trees and wrong prefix forms. A reliable method is to first fully parenthesize the infix expression, then carefully convert each group in a systematic manner. Final Answer: The correct prefix notation for the expression is - * + A B C ^ - D E + F G.

Question 18

In C and POSIX style systems, what value does the low level read function return when it reaches the end of a file during a read operation?

Accepted Answer

Introduction / Context: C programming distinguishes between high level standard I O functions, such as getchar or fgetc, and low level system calls like read. Many learners confuse their return conventions. This question focuses on the POSIX style read function, which operates on file descriptors and returns a count of bytes read. Understanding its behavior at end of file is essential for writing correct file handling loops. Given Data / Assumptions: We are using the read function with a prototype similar to ssize_t read(int fd, void *buf, size_t count). The function attempts to read up to count bytes into the buffer from the file descriptor fd. The function returns the number of bytes actually read, which may be less than count. We want to know the return value when the file position is already at the end of file. Concept / Approach: The read function has three main outcomes. On success, it returns a nonnegative value equal to the number of bytes read. If an error occurs, it returns -1 and sets errno to an appropriate error code. When end of file is reached before any bytes are read, read returns 0. This convention allows programs to distinguish between an error and a clean end of file condition and is different from the EOF macro used by functions like fgetc. Step-by-Step Solution: Consider a loop that calls read repeatedly until no more data is available. As long as the file has data, read returns a positive number showing how many bytes were placed in the buffer. When the file position reaches the end and there are no bytes left to read, a subsequent call to read does not fill the buffer. In this situation, read returns 0 to signal that end of file has been reached and that no more bytes can be read. If read encounters an error instead, it returns -1 and sets errno, which is different from the end of file case. Verification / Alternative check: Example code in POSIX documentation often shows loops that check for the result of read and break when it returns 0, treating that as the normal termination of a file processing loop. This confirms that 0 indicates end of file rather than an error. Why Other Options Are Wrong: Option b confuses read with high level functions like fgetc, which use EOF as a symbolic negative value to represent both end of file and some errors. Option c suggesting a final value of 1 has no special meaning; smaller positive counts can occur anywhere, not only at end of file. Option d is incorrect because read has well defined return semantics specified by the operating system interface, not compiler dependent behavior. Common Pitfalls: A frequent mistake is to test for end of file by comparing the return value of read to EOF instead of 0, which leads to incorrect logic. Another pitfall is ignoring the difference between system level read and buffered standard library calls. Always remember that read returns byte counts, with 0 used specifically to signal that no more data is available. Final Answer: When read reaches the end of a file, it returns 0 to indicate that no more bytes are available and that the calling code has reached the end of file.

Question 19

In the following C program that uses function pointers and console functions, what output is produced on the screen? #include #include int main() { void (*p)(); int (*q)(); int (*r)(); p = clrscr; …

Accepted Answer

Introduction / Context: This question tests understanding of function pointers in C and basic console functions from traditional DOS style libraries. Even though clrscr and getch come from nonstandard headers, the logic of the program can still be analyzed. The goal is to determine what is printed and how the function pointers are used. Given Data / Assumptions: The program declares three function pointers: p for a function returning void, q and r for functions returning int. p is assigned clrscr, q is assigned getch and r is assigned puts. The sequence of calls is to clear the screen, print a string and then wait for a key press. We assume a traditional environment where clrscr clears the screen, puts prints a string followed by a newline and getch waits for a key without echo. Concept / Approach: In C, function names decay to pointers to functions of the appropriate type, so assigning p = clrscr is valid if types are compatible. Calling a function pointer uses the same syntax as calling the function itself, either p() or (*p)(). The puts function prints the given string followed by a newline. The getch function reads a single keystroke and typically returns its code. Step-by-Step Solution: The program starts and assigns the addresses of clrscr, getch and puts to p, q and r respectively. The call (*p)() invokes clrscr, which clears the console screen. The call (*r)("www.curioustab.com") invokes puts with the given string, so the program prints www.curioustab.com followed by a newline. The call (*q)() invokes getch, which waits for the user to press a key before proceeding. After the key press, main returns and the program terminates. Verification / Alternative check: If you rewrite the code without function pointers and call clrscr(), puts("www.curioustab.com") and getch() directly, the behavior clearly matches the description. Using function pointers in this way does not change the observable output, only how the functions are referenced. Why Other Options Are Wrong: Option a is wrong because puts prints the string and there is nothing that suppresses this output. Option c assumes a compilation error, but function pointer assignments are valid when the signatures match reasonably well in this environment. Option d suggests that only a single character is printed, which would require a different function such as putchar rather than puts. Common Pitfalls: Learners sometimes think that using function pointers drastically changes behavior, but in most simple cases it only adds indirection. Another pitfall is to confuse nonstandard functions like clrscr and getch with standard C, but the question expects you to focus on logical behavior rather than strict portability. Final Answer: The program clears the screen, displays the text www.curioustab.com and then waits for the user to press a key before terminating.

Question 20

In C programming, consider the following code:  main() {     char a[] = "Visual C++";     char *b  = "Visual C++";      printf(" %d %d", sizeof(a), sizeof(b));     printf(" %d %d", sizeof(*a), sizeof(*b)); }  What values are printed by the two print…

Accepted Answer

Introduction / Context: This question examines the difference between an array of characters and a pointer to a string literal in C, and how the sizeof operator behaves for each. It is a classic test of understanding how strings are stored in memory and how pointers differ from arrays. Given Data / Assumptions: The array a is declared as char a[] = "Visual C++"; which creates an array sized to hold the string and its terminating null character. The pointer b is declared as char *b = "Visual C++"; which makes b point to a string literal stored elsewhere. We assume a 32 bit system where the size of a char pointer is 4 bytes. The printf calls print sizes using the %d format. Concept / Approach: For an array variable, sizeof gives the total size of the array in bytes. For a pointer variable, sizeof gives the size of the pointer itself, not the length of the string it points to. For a char, sizeof(*a) and sizeof(*b) both evaluate to the size of a single char, which is 1 byte on almost all systems. The string "Visual C++" has 10 visible characters plus a terminating null, so the array has length 11. Step-by-Step Solution: Count the characters in "Visual C++": V i s u a l gives 6, the space makes 7, C makes 8, plus and plus make 9 and 10. Add one for the closing null terminator, giving 11 bytes in the array. Therefore sizeof(a) is 11. b is a pointer to char, so sizeof(b) is the size of a pointer, which is 4 bytes on the assumed 32 bit system. The expression *a is a char, since a is an array of char, so sizeof(*a) is 1. Similarly, *b is also a char, so sizeof(*b) is 1. The first printf therefore prints 11 4 and the second prints 1 1. Verification / Alternative check: You can verify this behavior by compiling similar code on a 32 bit environment and printing the sizes. The output will show the array length including the null terminator for a, the pointer size for b and the element size for both dereferenced expressions. Why Other Options Are Wrong: Options that use 10 for sizeof(a) ignore the null terminator that is automatically added to string literals stored in arrays. Options with 2 for pointer size do not match the assumed 32 bit environment and are more typical of older 16 bit compilers. Options that show 4 for sizeof(*b) misinterpret the dereferenced pointer as another pointer instead of a char. Common Pitfalls: A common mistake is to think that sizeof on a pointer will somehow return the length of the string it points to. In C, sizeof is purely about the type size at compile time, not about runtime length of dynamic data. Another pitfall is forgetting the terminating null character when counting characters in a string literal. Final Answer: The program prints 11 4 on the first line and 1 1 on the second line, so the correct option is 11 4 followed by 1 1.

Programming Questions