Question 1

In the context of 8086-style segmented memory addressing in C (for example, Turbo C on DOS), how can you obtain the segment and offset parts from a far pointer that holds the address of a memory location?

Accepted Answer

Introduction / Context:On older x86 real-mode systems such as DOS, memory was addressed using segment:offset pairs. Compilers like Turbo C supported near, far, and huge pointers to work within this segmented memory model. A far pointer internally stored both the segment and offset parts of an address. Many low-level or systems programming tasks required extracting these individual components. Given Data / Assumptions:We are working in a 16-bit segmented memory model such as 8086 real mode.A far pointer holds both a 16-bit segment and a 16-bit offset.The question asks how to obtain segment and offset from such a far pointer in C.We assume we are using a DOS-era compiler like Turbo C that provides helper macros. Concept / Approach:In these compilers, a far pointer is represented as a 32-bit quantity, with the high 16 bits holding the segment and the low 16 bits holding the offset. Instead of manually shifting and masking bits, the runtime library usually provides macros to extract these parts safely. Turbo C, for example, defines FP_SEG(ptr) to return the segment part and FP_OFF(ptr) to return the offset part of a pointer. Using these macros is the standard and portable way, within that environment, to access the underlying segment and offset. Step-by-Step Solution:Step 1: Declare a far pointer, for example char far *p, that points to a memory location.Step 2: Use the macro FP_SEG(p) to obtain the 16-bit segment value associated with p.Step 3: Use the macro FP_OFF(p) to obtain the 16-bit offset value associated with p.Step 4: These macros internally perform the correct shifts and masks based on the compiler representation of far pointers.Step 5: The resulting segment and offset can then be used for interrupt calls, hardware programming, or debugging displays. Verification / Alternative check:Turbo C reference manuals and header files demonstrate these macros and their usage. Sample code often shows printf("%X:%X", FP_SEG(p), FP_OFF(p)); to print a segment:offset address. The macros are widely used in legacy DOS code, confirming that this is the idiomatic way to obtain the components from a far pointer. Why Other Options Are Wrong:Option B suggesting dividing by 10 has no basis in how segments and offsets are encoded; segment calculations involve multiples of 16, not 10. Option C incorrectly describes the transformation; far pointers are not manipulated by simple multiplication to obtain segments and offsets. Option D is wrong because compilers explicitly expose segment and offset through FP_SEG and FP_OFF, so it is definitely possible. Common Pitfalls:Programmers sometimes try to rely on assumptions about pointer representation and manually shift or cast values. This is error prone and non-portable even across compilers targeting the same hardware. Another pitfall is forgetting that modern protected-mode and 64-bit environments do not use segment:offset addressing the same way, so FP_SEG and FP_OFF are obsolete outside of legacy DOS programming. Final Answer:You can obtain the segment and offset from a far pointer by using FP_SEG(pointer) to get the segment and FP_OFF(pointer) to get the offset.

Question 2

In C, consider the following program. Assume that the array arr begins at address 65486 in memory.  int main(void) {     int arr[] = {12, 14, 15, 23, 45};     printf("%u %u", arr, &arr);     return 0; }  What values will be printed, given that sizeo…

Accepted Answer

Introduction / Context:This question explores how array names and the address-of operator work in C when printing addresses. Although arr and &arr have different types, they both refer to the same starting memory location for the array. Understanding this distinction is important for pointer arithmetic and for avoiding confusion when passing arrays to functions. Given Data / Assumptions:The array arr has 5 int elements and begins at address 65486.sizeof(int) is 2 bytes on the target system.The program prints arr and &arr using the %u format specifier.We are only concerned with the numeric address values printed, not with strict type safety of printf. Concept / Approach:In most expressions, the array name arr decays to a pointer to its first element, that is, a value of type int * pointing to arr[0]. The expression &arr, on the other hand, is the address of the entire array object and has type int (*)[5]. Despite the different types, both pointers contain the same memory address, namely the starting address of the array in memory. Differences appear only when we perform pointer arithmetic on these pointers, not when we simply print their raw address values. Step-by-Step Solution:Step 1: The starting address of arr[0] is given as 65486.Step 2: The expression arr in the printf call decays to &arr[0], which holds the address 65486.Step 3: The expression &arr is the address of the whole array object, which is also located at the same starting address 65486.Step 4: Therefore, both arguments to printf refer to the same underlying address.Step 5: When printed with %u, the output will be two identical numbers: 65486 65486. Verification / Alternative check:If we extended the example and printed arr + 1 and &arr + 1, we would see different values: arr + 1 would point to the second element and be 65488 (2 bytes ahead), while &arr + 1 would point one whole array size ahead, moving by 5 * sizeof(int). However, for the base addresses arr and &arr, both represent the starting memory location of the array, confirming that they print the same value. Why Other Options Are Wrong:Option B (65486 65496) would correspond to treating &arr as if it were already incremented by one array length, which does not happen here. Option C (65486 65488) incorrectly assumes that &arr is automatically offset by one element compared to arr. Option D is incorrect in practice because, although the types differ, many compilers allow this usage with a warning, and at run time the addresses are printed correctly. Common Pitfalls:Students often think that arr and &arr are completely different in both type and value. While they do have different types and behave differently under pointer arithmetic, they share the same starting address when not modified. Confusing their types can lead to subtle bugs, especially when passing &arr instead of arr to functions expecting int *. Final Answer:The program prints 65486 65486.

Question 3

In standard C (without compiler-specific extensions), consider the following code:  int main(void) {     int a = 10, *j;     void *k;     j = k = &a;     j++;     k++;     printf("%u %u", j, k);     return 0; }  Would this program compile successful…

Accepted Answer

Introduction / Context:This question checks understanding of pointer types and pointer arithmetic rules in standard C. While C allows implicit conversion between object pointers and void *, arithmetic on void * itself is not defined by the C standard. Some compilers provide it as an extension, but portable C code must avoid incrementing or decrementing a void pointer directly. Given Data / Assumptions:a is an int variable.j is an int * pointer and k is a void * pointer.The assignment j = k = &a; converts &a to void * and then to int *.The code then performs j++ and k++ and attempts to print both pointers.We are considering standard C, not compiler-specific extensions. Concept / Approach:Standard C allows assigning the address of any object to a void * pointer, and a void * can be converted back to the original pointer type. However, pointer arithmetic (such as p++, p--, p + n, p - n) is only defined on pointers to complete object types, such as int *, char *, or struct mytype *. A void does not have a defined size, so the compiler cannot know how far to advance a void * when performing k++. For this reason, arithmetic on void * is not allowed by the C standard and should result in a compilation error. Step-by-Step Solution:Step 1: The line j = k = &a; is legal because &a (type int *) can be implicitly converted to void * for k, and assigned back to int * for j.Step 2: The statement j++ is valid because j is an int * pointer, and pointer arithmetic on int * is defined to move by sizeof(int) bytes.Step 3: The statement k++ attempts to perform pointer arithmetic on a void * pointer.Step 4: In standard C, void has no size, so the compiler cannot calculate the correct increment for k++.Step 5: Therefore, a conforming compiler must reject k++ with a compilation error, and the program will not compile successfully under standard C rules. Verification / Alternative check:If you compile this code with a strictly conforming C compiler, you will typically see an error such as "arithmetic on pointer to void" or "invalid use of void expression". Some compilers (for example, GCC with GNU extensions) may treat void * as if it were char * and allow k++, but this behavior is non-standard and should not be relied upon in portable code. Why Other Options Are Wrong:Option B is incorrect because the standard does not define arithmetic on void *; any compiler that accepts it is using an extension. Option C is wrong because assigning &a to a void * is allowed; void * is explicitly designed to hold pointers to any data type. Option D is incorrect because j++ on an int * is perfectly well-defined; it moves the pointer by sizeof(int) bytes. Common Pitfalls:A common mistake is to assume that void * behaves like a generic pointer that supports all operations, including arithmetic. In reality, it is only a generic container for addresses and must be converted to a specific pointer type before doing arithmetic or dereferencing. Another pitfall is relying on compiler extensions; such code may fail to compile or behave differently on other compilers or platforms. Final Answer:The program will not compile in standard C because pointer arithmetic on a void pointer (k++) is not allowed.

Question 4

In a DOS/Turbo C style C program, you want to write the character 'A' directly to video memory at segment B800h, offset 0000h using a far pointer. The following code generates a warning:  int main(void) {     char far *scr;     scr = 0xB8000000;    …

Accepted Answer

Introduction / Context:In older DOS programming with Turbo C or similar compilers, programmers sometimes wrote directly to video memory at segment B800h for text mode output. This required using far pointers to specific segment:offset addresses. Assigning a numeric constant directly to a pointer without a cast can cause the compiler to issue a warning because of the type mismatch between integer literals and pointer types. Given Data / Assumptions:scr is declared as char far *scr; which is a far pointer to character.The literal 0xB8000000 represents the segment:offset address B800:0000 encoded in a 32-bit value.The code scr = 0xB8000000; assigns an integer constant directly to a pointer variable.The question asks how to eliminate the warning while keeping the intended address assignment. Concept / Approach:In C, assigning an integer literal directly to a pointer usually produces a warning, because the compiler wants an explicit cast when converting between integers and pointers. The correct way to indicate that you are intentionally treating a numeric literal as a pointer is to cast the literal to the appropriate pointer type. In this case, scr should be assigned (char far *)0xB8000000L, making the conversion explicit and silencing the warning on compilers that support far pointers. Step-by-Step Solution:Step 1: Keep scr declared as char far *scr; so that it can point to the video memory region.Step 2: Change the assignment from scr = 0xB8000000; to scr = (char far *)0xB8000000L; adding both a type cast and an appropriate literal suffix.Step 3: The cast (char far *) tells the compiler to interpret the integer constant as a far pointer to char.Step 4: The L suffix ensures that the constant is treated as a long value, matching the size of a far pointer on that platform.Step 5: With this explicit cast, the compiler understands the programmer intent and suppresses the type mismatch warning. Verification / Alternative check:Turbo C documentation and example code often show assignments such as char far *scr = (char far *)0xB8000000L; for direct video memory access. These examples compile without warnings when using the correct cast. If you remove the cast, the compiler warns about converting from long to pointer without an explicit cast, which is exactly the situation described in the original code. Why Other Options Are Wrong:Option B suggests changing scr to int, but then *scr = 'A' would be invalid because scr would no longer be a pointer to char. Option C is incorrect because leaving scr uninitialized and relying on a default value is unsafe and does not assign the desired video memory address. Option D is wrong because the whole purpose of the cast is to indicate intentional conversion, which is a standard technique to eliminate such warnings. Common Pitfalls:Programmers sometimes ignore compiler warnings about pointer and integer conversions, which can hide real bugs. It is better practice to use explicit casts when intentionally converting between integers and pointers, especially in low-level code. Another pitfall is forgetting that these techniques are specific to legacy 16-bit environments and are not portable to modern protected-mode or 64-bit systems. Final Answer:You should explicitly cast the literal, for example scr = (char far *)0xB8000000L;, to eliminate the warning.

Question 5

In C, consider the following program compiled with a typical 16-bit compiler where char is 1 byte and int is 2 bytes:  int main(void) {     char ch = 'A';     printf("%d%d", sizeof(ch), sizeof('A'));     return 0; }  What will this program print?

Accepted Answer

Introduction / Context:This question tests understanding of the sizeof operator and the types of character literals in C, especially in the context of older 16-bit compilers. While a char variable clearly has size 1 byte, a character literal such as 'A' may have type int rather than char, causing sizeof('A') to differ from sizeof(ch). Recognizing this distinction is important for writing portable code and for interpreting sizeof results correctly. Given Data / Assumptions:We are using a typical 16-bit C compiler where sizeof(char) is 1 and sizeof(int) is 2.ch is declared as char ch = 'A'; so ch is of type char.The expression sizeof(ch) returns the size of the char variable.The expression sizeof('A') returns the size of the type of the character literal 'A'. Concept / Approach:In C, character literals like 'A' are of type int, not char, unless a specific wide or other literal notation is used. Therefore sizeof('A') is actually sizeof(int). On a 16-bit system, int is typically 2 bytes. On the other hand, sizeof(ch) is the size of a char, which is 1 byte. When printf prints these two values back to back with %d%d, the resulting output will be the digits 1 and 2 with no space in between. Step-by-Step Solution:Step 1: Determine sizeof(ch). Because ch is of type char, sizeof(ch) = 1 byte on the given system.Step 2: Determine the type of the literal 'A'. In standard C, a plain character literal like 'A' has type int.Step 3: On a 16-bit compiler, sizeof(int) = 2 bytes, so sizeof('A') = 2.Step 4: The printf call uses "%d%d", so it prints the first integer (1) immediately followed by the second integer (2).Step 5: Therefore, the visible output is the two-digit sequence 12. Verification / Alternative check:On many compilers, you can test the types by using expressions like if (sizeof('A') == sizeof(int)) or using typeof extensions. The C standard confirms that character constants like 'A' are of type int. Running a small test program that prints sizeof(char) and sizeof('A') will typically show 1 and 2 on older 16-bit systems, confirming the analysis. Why Other Options Are Wrong:Option B (11) would require both sizeof(ch) and sizeof('A') to be 1, which is not the case when 'A' has type int. Option C (21) and Option D (22) mismatch at least one of the sizes and do not respect the given data about char and int sizes. The correct combination for this environment is 1 and 2, yielding 12. Common Pitfalls:Many programmers mistakenly assume that character literals are of type char. This can lead to surprises in sizeof expressions and in function overloading in C++. Another pitfall is forgetting that printf("%d%d", ...) prints values without spaces; if you want "1 2" you must write "%d %d". Understanding literal types and format strings helps avoid such confusion. Final Answer:The program prints 12.

Question 6

In C, consider the following typedef declaration for a linked list node pointer:  typedef struct {     int data;     NODEPTR link; } *NODEPTR;  What is the error, if any, in this code?

Accepted Answer

Introduction / Context:This question examines how typedef and struct declarations interact in C, especially when defining self-referential structures such as linked list nodes. A common pattern is to have a struct that contains a pointer to the same struct type. However, care must be taken to use struct tags correctly and to avoid referring to a typedef name before it has been fully defined. Given Data / Assumptions:We have a typedef that intends to introduce NODEPTR as a pointer type to a struct.The struct itself contains a field of type NODEPTR named link.The typedef syntax is: typedef struct { int data; NODEPTR link; } *NODEPTR;We are using standard C rules for declarations and typedefs. Concept / Approach:During the parsing of this declaration, the compiler processes the struct body first. Inside the struct body, the identifier NODEPTR is used as if it were already a known type. However, the typedef that defines NODEPTR as a type name is only completed after the closing brace of the struct. Therefore, inside the struct definition, NODEPTR has not yet been introduced as a typedef, and its use as a field type is invalid. The correct way to make a self-referential struct is to give the struct a tag and use a pointer to that tag, not the typedef name being defined. Step-by-Step Solution:Step 1: Observe that NODEPTR is intended to be a typedef for "pointer to struct { ... }".Step 2: Note that inside the struct body, the field link is declared as NODEPTR link; which assumes that NODEPTR is already a known type.Step 3: Recognize that the typedef is not in effect until the entire declaration is completed after the closing brace and name NODEPTR.Step 4: Therefore, at the point where NODEPTR is used inside the struct, it is not yet defined, causing a compilation error.Step 5: A correct form would be:typedef struct node { int data; struct node *link;} *NODEPTR; Verification / Alternative check:Trying to compile the original code on a standard C compiler typically results in an error such as "unknown type name NODEPTR" for the link field. When the struct is given a tag and the pointer field uses struct node *, the code compiles correctly, confirming that the problem is with the premature use of the typedef name. Why Other Options Are Wrong:Option B is incorrect because anonymous structs (struct without a tag) are allowed in C, especially in combination with typedefs. Option C is wrong because int is a perfectly valid field type inside a struct. Option D is incorrect because the code as written does not conform to the rule about using typedef names only after they are defined. Common Pitfalls:Programmers sometimes try to define a typedef and use it inside the same declaration without realizing the ordering rules. Another pitfall is confusion between struct tags and typedef names. The usual safe pattern is to first declare a struct with a tag and then create typedefs or pointer types based on that tag. Final Answer:The error is that NODEPTR is used as a type inside the struct before the typedef that defines NODEPTR has been completed.

Question 7

In C, consider the following code that writes a structure to a file using fwrite:  struct emp {     char *n;     int age; };  struct emp e = { "Sujay", 15 }; FILE *fp;  /* assume fp is a valid file pointer opened in binary write mode */ fwrite(&e, s…

Accepted Answer

Introduction / Context:Binary file I/O in C using fwrite and fread is often used to persist structures to disk. However, when structures contain pointers, simply writing the structure memory does not automatically serialize the data pointed to. Understanding this distinction is critical for designing portable and correct file formats. Given Data / Assumptions:The structure emp contains a pointer field char *n and an int field age.The instance e initializes n to point to the string literal "Sujay".fwrite(&e, sizeof(e), 1, fp); writes the raw bytes of the struct e to the file.We want to know whether fread can later read the struct back and recover the original string correctly. Concept / Approach:The expression fwrite(&e, sizeof(e), 1, fp); writes the in-memory representation of the struct, including the numeric value stored in the pointer n and the integer age. It does not write the characters of the string "Sujay" themselves, only the address of that string in the current process address space. When the file is read back, the raw pointer value is restored, but this numeric address will not correspond to a valid string in the new process. Therefore, the reconstructed structure will contain an invalid pointer, and the original string data is not reliably preserved. Step-by-Step Solution:Step 1: Recognize that n is a pointer, not an embedded character array.Step 2: During fwrite, the bytes corresponding to the pointer n and the integer age are written.Step 3: The actual characters 'S', 'u', 'j', 'a', 'y', and the null terminator reside in program memory as part of a string literal and are not written by this fwrite call.Step 4: Upon fread, the pointer value n is restored as a numeric address, but in the new run this address is almost certainly meaningless or invalid.Step 5: Therefore, the original string "Sujay" cannot be reliably reconstructed using a single fread of this structure. Verification / Alternative check:Practical experience shows that writing pointer-containing structures with fwrite leads to portability and correctness problems. Texts on C file I/O recommend that only structures with fixed-size, non-pointer members (for example, char arrays, ints, doubles) be written with a simple fwrite, or that custom serialization be implemented to write and read pointed-to data separately. This supports the conclusion that the given code does not robustly serialize the string. Why Other Options Are Wrong:Option B is incorrect because pointer values are process-specific addresses; they have no meaning across different executions or machines. Option C is wrong because the issue is not the size of int, but the presence of a pointer that is not dereferenced during I/O. Option D is incorrect because fread can certainly read structures composed of simple, non-pointer fields; it is the presence of pointers that makes this case unsafe. Common Pitfalls:A common mistake is to assume that fwrite and fread magically handle all nested data, including what pointers reference. In reality, binary serialization must explicitly manage any dynamically allocated or pointed-to memory. Another pitfall is testing such code only in a single run where addresses coincidentally look valid, hiding the underlying bug until later. Final Answer:The structure cannot be safely reconstructed with a single fread, because only the pointer value n is written, not the bytes of the string "Sujay", so reading it back does not reliably restore the original string.

Question 8

In C, consider the following program compiled on a typical system where string literals are stored in read-only memory:  int main(void) {     struct emp {         char *n;         int age;     };      struct emp e1 = { "Dravid", 23 };     struct emp…

Accepted Answer

Introduction / Context:This question illustrates the difference between copying a structure that contains a pointer and copying the data being pointed to. It also highlights the potential dangers of modifying string literals in C. When a struct with a char * field is assigned to another struct, the pointer value is copied, not the underlying string. As a result, two structures may share the same string in memory, and modifying the string through one pointer affects what is seen through the other. Given Data / Assumptions:struct emp has two fields: a pointer to char n and an int age.e1 is initialized with n pointing to the string literal "Dravid".e2 is assigned e1, so e2.n receives the same pointer value as e1.n.strupr(e2.n) converts the characters of the string pointed to by e2.n to uppercase, in place.We assume a non-strict, legacy environment where modifying string literals happens to work, even though it is undefined behavior in standard C. Concept / Approach:When we write struct emp e2 = e1;, C performs a shallow copy of the structure. This means that the pointer n in e2 becomes equal to the pointer n in e1; both point to the same memory location where "Dravid" is stored. Calling strupr(e2.n) passes that pointer to the function, which then modifies each character of the string to its uppercase equivalent. Because e1.n and e2.n refer to exactly the same characters, printing e1.n afterwards shows the modified, uppercase version of the string. Step-by-Step Solution:Step 1: Initialize e1.n with the address of the string literal "Dravid".Step 2: Assign e2 = e1;, which sets e2.n to the same address as e1.n; the age field is also copied.Step 3: Call strupr(e2.n). The function reads each character from the shared string and converts it to uppercase.Step 4: After this call, the contents of the memory region originally holding "Dravid" are transformed to "DRAVID".Step 5: printf("%s", e1.n); prints the string pointed to by e1.n, which is now "DRAVID". Verification / Alternative check:If instead of a pointer we had used an embedded character array in the struct, for example char n[20];, then struct assignment would copy the characters themselves, and e1.n and e2.n would refer to independent buffers. In that case, modifying e2.n would not change e1.n. The fact that the code uses char *n demonstrates that only the pointer is copied, not the underlying string contents, explaining why e1.n reflects the change. Why Other Options Are Wrong:Option B ("Dravid") would be correct only if the string had been duplicated or if e1.n pointed to a different memory location from e2.n. Option C claiming that it always crashes is not necessarily true in permissive environments, although modifying string literals is undefined behavior and may crash on some systems. Option D is wrong because neither pointer is set to NULL in the code; they both continue to point to the shared string. Common Pitfalls:A major pitfall is assuming that assigning structures or pointers automatically performs deep copies of the data they refer to. In C, struct assignment is a shallow copy that copies pointer values as-is. Another pitfall is modifying string literals; the C standard states that attempting to change them is undefined behavior, so the safe approach is to copy such strings into writable arrays first. Final Answer:Under the stated assumptions, the program prints DRAVID.

Question 9

In C programming, you have two structure variables of the same type. What is a safe and portable way to check whether the contents of these two structures are the same?

Accepted Answer

Introduction / Context:Checking whether two structure variables contain the same logical data can be necessary when implementing equality checks, caching, or debugging. However, structures in C may contain padding bytes and pointers, and the language does not define a built-in == operator for structures. A careful, field-by-field comparison is needed to avoid undefined or misleading results. Given Data / Assumptions:We have two variables s1 and s2 of the same struct type.The struct may contain basic types, arrays, and possibly pointers.We want to know whether s1 and s2 represent the same logical information.We need a method that is portable and does not depend on compiler-specific padding or memory layout. Concept / Approach:C does not provide a direct == operator for comparing whole structures. While some programmers are tempted to use memcmp on the raw memory, this can be unsafe because of padding bytes and uninitialized fields, which may differ even when the logical contents are the same. The robust approach is to compare each field of the structure individually using appropriate comparison operators (for example, == for integers, strcmp for strings, separate logic for pointers). Step-by-Step Solution:Step 1: Identify all fields in the structure definition, such as int id; double salary; char name[50]; and so on.Step 2: Write a function or code snippet that compares s1.id == s2.id, s1.salary == s2.salary, and strcmp(s1.name, s2.name) == 0 for string fields.Step 3: For pointer fields, decide whether equality means pointing to the same address or to equal data, and implement the correct comparison.Step 4: Combine the comparisons using logical AND so that all fields must match for the structures to be considered equal.Step 5: Return true if all fields match, false otherwise. Verification / Alternative check:Trying to use s1 == s2 directly will fail to compile, as C does not define == for struct types. Using memcmp(&s1, &s2, sizeof(struct type)) might appear to work in simple cases, but can produce false negatives if padding bytes differ or if the compiler introduces different internal layouts. Field-by-field comparison, on the other hand, is explicit and respects the logical meaning of each field. Why Other Options Are Wrong:Option B is invalid because == cannot be applied directly to structures in C; it is only defined for scalar types and pointers. Option C using memcmp is not reliably portable due to padding and possible uninitialized data, making equality dependent on implementation details rather than logical content. Option D compares only the addresses of the structure variables, which merely checks whether they are the same object in memory, not whether their contents match. Common Pitfalls:Relying on memcmp for structure equality can lead to subtle bugs when structures contain padding, bit-fields, or pointers. Another pitfall is forgetting that pointer fields may require deep comparisons (comparing pointed-to data) rather than shallow comparisons of addresses. Writing a dedicated equality function for each struct type is usually the safest and clearest approach. Final Answer:A safe way to check equality is to compare each corresponding member field of the two structures individually for equality.

Question 10

In C, consider the following program that attempts to read and print all lines from a text file:  #include "stdio.h"  int main(void) {     FILE *fp;     char str[80];      fp = fopen("trail", "r");     while (!feof(fp)) {         fgets(str, 80, fp);…

Accepted Answer

Introduction / Context:This question tests understanding of how end-of-file (EOF) is detected when reading from files in C. A frequently seen but incorrect idiom is while (!feof(fp)) { fgets(...); ... }. This pattern can lead to using invalid data or printing the last line twice. The correct way is to check the return value of the input function itself. Given Data / Assumptions:fp is a FILE pointer opened in read mode for a text file named "trail".Each iteration of the loop calls fgets(str, 80, fp) and then prints the line with puts.The loop condition is while (!feof(fp)).We assume normal file contents and no prior EOF condition. Concept / Approach:The feof function only reports the end-of-file condition after an attempt has been made to read past the end of the file. In the while (!feof(fp)) pattern, the loop continues even after the last successful read. On the final iteration, fgets fails and returns NULL, but the loop body still executes and may print stale data from the previous iteration. The proper approach is to use fgets return value in the loop condition: while (fgets(str, 80, fp) != NULL) { puts(str); }. Step-by-Step Solution:Step 1: Start reading lines using fgets. As long as data is available, fgets returns str; when there is no more data, it returns NULL.Step 2: Note that feof(fp) does not become true until after a read attempt fails at EOF.Step 3: With the pattern while (!feof(fp)), the loop condition is checked before attempting the read, so the loop runs one extra time after the last successful read.Step 4: On this extra iteration, fgets returns NULL, but puts(str) is still called, potentially printing the last line twice or using uninitialized data.Step 5: The correct pattern is: while (fgets(str, 80, fp) != NULL) { puts(str); }, which stops as soon as no more data can be read. Verification / Alternative check:Many C programming references explicitly warn against the while (!feof(fp)) idiom. Sample code and best practice guides show loop conditions based on the return value of fgets, scanf, or fread. Testing the original code with a small file often reveals an extra blank line or duplicated output at the end, confirming the logical error. Why Other Options Are Wrong:Option B is incorrect because fgets is perfectly suitable for reading lines; there is no requirement to use scanf. Option C is wrong; fclose is necessary to release file resources properly. Option D is incorrect because the pattern shown is widely recognized as a flawed way to read until EOF. Common Pitfalls:A common trap is to think that feof predicts the future end-of-file condition before reading. Instead, it only reports EOF after a read fails. Another pitfall is ignoring the return value of input functions, which is the primary indicator of success or failure of the read operation. Using proper loop conditions avoids these subtle bugs. Final Answer:The logical error is that using while (!feof(fp)) is incorrect; the loop should test the return value of fgets instead.

Question 11

In C, consider this program saved as sample.c:  int main(int argc, char **argv) {     argc = argc - (argc - 1);     printf("%s", argv[argc - 1]);     return 0; }  Regardless of how many command-line arguments are supplied, what does this program pri…

Accepted Answer

Introduction / Context:This question focuses on command-line arguments in C and how argc and argv work. The program performs an unusual manipulation of argc before using it to index into argv. Understanding the algebraic simplification of the expression and the meaning of argv elements is key to predicting the output. Given Data / Assumptions:argc is the count of command-line arguments, including the program name.argv is an array of pointers to strings, where argv[0] is the program name and argv[1]..argv[argc - 1] are additional arguments.The code reassigns argc with argc = argc - (argc - 1); and then prints argv[argc - 1].We assume argv is well-formed and argc is at least 1. Concept / Approach:We first simplify the assignment to argc and see what value it takes, regardless of its original value. Then we evaluate argv[argc - 1] with this new argc. Since argv[0] is defined as the program name, if argc becomes 1, argv[argc - 1] will always be argv[0], which is the program name string. Step-by-Step Solution:Step 1: Let the original value of argc be N (where N ≥ 1).Step 2: Compute the new argc by substituting: argc = argc - (argc - 1).Step 3: Algebraically, N - (N - 1) simplifies to N - N + 1 = 1.Step 4: Therefore, after the assignment, argc is always 1, no matter how many arguments were supplied initially.Step 5: The program then prints argv[argc - 1] which is argv[1 - 1] = argv[0], the program's own name. Verification / Alternative check:If you run the program as ./sample 10 20 30, the original argc is 4. After the assignment, argc becomes 1, and argv[0] still points to "./sample". If you run it with no extra arguments, argc starts as 1 and remains 1 after the assignment, so argv[0] is still the program name. In all cases, argv[0] is printed, confirming the analysis. Why Other Options Are Wrong:Option B claims that the last command-line argument is printed, which would be argv[argc - 1] using the original argc, not the modified value. Option C suggests the first argument after the program name, which would be argv[1], but the code uses argv[0]. Option D is wrong because argv[0] is a valid string containing the program path or name, so printing it does not yield an empty string. Common Pitfalls:Students sometimes forget that argc includes the program name and only think about user-supplied arguments. Another pitfall is not simplifying the assignment algebraically and trying to reason through specific examples only. Recognizing that argc is forced to 1 clarifies the behavior immediately. Final Answer:The program always prints the program's own name, that is, the string stored in argv[0].

Question 12

In C, consider the following program run from the command line as:  myprog 1 2 3  The source code is:  int main(int argc, char *argv[]) {     int i, j = 0;     for (i = 0; i < argc; i++)         j = j + atoi(argv[i]);     printf("%d", j);     return…

Accepted Answer

Introduction / Context:This question checks how command-line arguments are passed to main in C and how functions like atoi interpret them. The program iterates over all arguments, including the program name, converts each to an integer using atoi, and accumulates their sum in j. Understanding which arguments are numeric and how atoi treats non-numeric strings is essential to determine the final result. Given Data / Assumptions:The program is invoked as myprog 1 2 3 from the command line.argc is the count of arguments, including the program name; here argc = 4.argv[0] is "myprog", argv[1] is "1", argv[2] is "2", and argv[3] is "3".atoi converts a string to an int, returning 0 if the string does not start with a valid numeric sequence. Concept / Approach:The for loop runs from i = 0 to i < argc, visiting each argument string in argv. On each iteration, j is incremented by atoi(argv[i]). For numeric strings like "1", "2", and "3", atoi returns their integer values. For the program name "myprog", which does not begin with digits, atoi returns 0. The total sum is thus 0 + 1 + 2 + 3. Step-by-Step Solution:Step 1: Initialize j = 0.Step 2: On the first loop iteration, i = 0, argv[0] is "myprog". atoi("myprog") returns 0 because the string does not start with a digit. j remains 0.Step 3: On the second iteration, i = 1, argv[1] is "1". atoi("1") returns 1, so j becomes 0 + 1 = 1.Step 4: On the third iteration, i = 2, argv[2] is "2". atoi("2") returns 2, so j becomes 1 + 2 = 3.Step 5: On the fourth iteration, i = 3, argv[3] is "3". atoi("3") returns 3, so j becomes 3 + 3 = 6.Step 6: The loop ends when i reaches argc (4). The program then prints j, which is 6. Verification / Alternative check:You can mentally simulate atoi on each argument or run a similar test program. It is also helpful to remember that robust argument-summing programs usually start the loop at i = 1 to skip argv[0]. The fact that this program starts at i = 0 just adds an extra 0 from atoi("myprog"), which does not change the sum. Why Other Options Are Wrong:Option A (123) would correspond to concatenating the digits as a string, not summing them. Option C (Error) is incorrect because atoi handles non-numeric inputs by returning 0 rather than causing a run-time error. Option D ("123") would involve printing text, but the program prints an integer value without quotes or concatenation. Common Pitfalls:A common mistake is to assume that argv[0] is the first numeric argument, forgetting that it is actually the program name. Another pitfall is expecting atoi to throw an error on invalid input; instead, it returns 0 and does not report the failure unless additional checking is done with functions like strtol. Final Answer:The program prints the sum 1 + 2 + 3, which is 6.

Question 13

In C, what will be the output of the following program that uses an unsigned int and the bitwise NOT operator?  main() {     unsigned int a = 0xffff;  /* hexadecimal constant */     ~a;     printf("%x", a); }

Accepted Answer

Introduction / Context: This question tests understanding of how expressions, side effects and the bitwise NOT operator work in C when applied to an unsigned int. Many learners focus only on the mathematical effect of the operator and forget that the result of an expression is not automatically stored back into the original variable unless there is an explicit assignment. The program also uses hexadecimal formatting with printf, so you must combine knowledge of bitwise operators and output formatting. Given Data / Assumptions: a is declared as unsigned int and initialised with the constant 0xffff, which is 65535 in decimal. The expression ~a is evaluated but its result is not assigned back to a. printf is called with the format "%x" to print an unsigned value in lowercase hexadecimal. We assume a typical implementation where unsigned int is at least 16 bits or larger. Concept / Approach: The key idea is that the statement ~a; computes the bitwise complement of a but discards the result, because there is no assignment. Side effects occur only when operators modify objects, for example with +=, *= or the increment operators. A plain unary operator like ~ produces a temporary value. Therefore the value stored in a remains 0xffff. When printf prints a using "%x", it will display that unchanged value in hexadecimal. Step-by-Step Solution: Step 1: Start with a = 0xffff, so the stored value is hexadecimal ffff. Step 2: Evaluate the expression ~a. This computes the bitwise complement but does not update a because there is no assignment operator. Step 3: After the expression, the variable a still contains the original value 0xffff. Step 4: Call printf with "%x" and a. The function prints the value of a in hexadecimal without any leading prefix. Step 5: The output is therefore the string "ffff". Verification / Alternative check: If the intention were to store the complemented value back into a, the code would need to use a statement like a = ~a; or a ^= 0xffff; instead of just ~a;. Since that is not the case, reasoning about sequence points or integer width is not required. On common compilers, you can quickly test a similar program and see that the printed output is ffff, confirming the analysis. Why Other Options Are Wrong: Option B 0000 would be correct only if the complement were assigned back and the width matched exactly, which is not what this code does. Option C 0001 has no basis in the operations shown. Option D suggests that the result depends on the compiler or is undefined, but in this case the behaviour is well defined because the expression is evaluated and discarded and a retains its initial value. Common Pitfalls: A common mistake is to assume that writing an expression like ~a; somehow mutates a. In C, expressions without assignment or increment or decrement operators do not change variables. Another pitfall is to overcomplicate the question by worrying about the exact bit width of unsigned int. Here, the important point is that the value of a is never modified, so the initial hexadecimal value is printed unchanged. Final Answer: The program prints ffff because the bitwise NOT expression does not assign its result back to a, so printf prints the original value 0xffff in hexadecimal.

Question 14

In C bit manipulation, consider the following macros for treating a char array as a compact bit set:  #define CHARSIZE     8 #define MASK(y)      (1 << ((y) % CHARSIZE)) #define BITSLOT(y)   ((y) / CHARSIZE) #define SET(x,y)     ( (x)[BITSLOT(y)] |=…

Accepted Answer

Introduction / Context: This question checks understanding of how to design and use bit set style macros in C for memory efficient storage of many boolean flags. Instead of using an array of int with one element per flag, a bit set packs multiple bits into each byte. The macros provided implement a small domain specific language for setting and testing bits by index. You must interpret these macros correctly and apply them to a realistic usage scenario involving 50 bits and specific bit positions. Given Data / Assumptions: CHARSIZE is defined as 8 bits per byte. MASK(y) computes a bit mask with a single bit set at position y modulo 8. BITSLOT(y) computes which byte holds the bit with index y. SET(x,y) should set the bit y in the byte array x. TEST(x,y) should return nonzero if bit y is set. NUMSLOTS(n) gives the number of bytes required to hold n bits. Concept / Approach: To hold 50 bits, the code must allocate enough bytes for indices 0 through 49. NUMSLOTS(50) uses a ceiling style calculation: (50 + 8 - 1) / 8 equals 57 / 8, which is 7 with integer division, so seven bytes are sufficient. For setting a bit, we must call SET on the array, which uses BITSLOT and MASK internally. For testing, we must call TEST and interpret a nonzero result as true. Any solution that ignores NUMSLOTS, misuses indexes directly or fails to call SET and TEST correctly will be wrong. Step-by-Step Solution: Step 1: Compute the number of bytes: NUMSLOTS(50) equals 7, so declare arr as unsigned char arr[NUMSLOTS(50)]. Step 2: To turn on bit 20, use SET(arr, 20). This will compute BITSLOT(20) to choose the correct byte and OR in the mask for that bit. Step 3: To test bit 40, call TEST(arr, 40). If the bit is on, the result will be nonzero. Step 4: Wrap the test in an if statement: if (TEST(arr, 40)) { /* bit 40 is on */ }. Step 5: Verify that the array type, macros and indices are used consistently with the definitions in the stem. Verification / Alternative check: You can verify by hand for one index. For example, y equals 20 gives BITSLOT(20) equals 2, and MASK(20) equals 1 shifted by 4, so the fifth bit of arr[2] is set. For y equals 40 you get BITSLOT(40) equals 5 and MASK(40) equals 1 shifted by 0, which selects the lowest bit of arr[5]. This confirms that the macros operate as intended with the chosen declaration and calls. Why Other Options Are Wrong: Option B incorrectly allocates 50 bytes instead of seven and then negates the TEST result inside the if, which reverses the logical meaning. Option C uses an int array and directly assigns indices 20 and 40, ignoring the bit packing design entirely. Option D calls only MASK without actually writing to or reading from the array, so it does not set or test any bits in arr. Common Pitfalls: A common mistake when using such macros is to forget that BITSLOT and MASK are expressed in bytes and bit shifts, not in plain element counts. Another pitfall is to overwrite an entire byte instead of OR combining bits, which would lose previous flags. In exam questions, carefully read each macro and check that the suggested code respects both the array type and the index mapping logic. Final Answer: The correct usage is to declare unsigned char arr[NUMSLOTS(50)]; then call SET(arr, 20); to set bit 20 and use if (TEST(arr, 40)) { /* bit 40 is on */ } to test bit 40.

Question 15

In the following C code using an incomplete struct type and a typedef for a pointer, is it valid to introduce the typedef before the struct is fully defined, and can the pointer member next use that typedef?  typedef struct employee *ptr;  struct em…

Accepted Answer

Introduction / Context: Linked data structures in C often require a struct to contain a pointer to its own type, such as in linked lists or trees. The language supports this by allowing pointers to incomplete struct types. This question checks whether you understand how typedef interacts with forward declarations and incomplete types, and whether a typedef name for a pointer can be introduced before the full struct definition and then used inside that definition. Given Data / Assumptions: The code introduces typedef struct employee *ptr; before the struct body. struct employee is at that point an incomplete type because its members are not yet known. The struct is then fully defined with fields name, age and a member next of type ptr. We are working in standard C, not in C plus plus specific rules. Concept / Approach: C allows the use of a struct tag as soon as it has been introduced, even if the complete definition comes later. This is called an incomplete type. You cannot take sizeof an incomplete type or define variables of that exact type, but you can declare pointers to it. A typedef that names a pointer to an incomplete struct is therefore legal. Once the full struct definition appears, the typedef name ptr refers to a pointer to that now complete struct type, and the member declaration ptr next; is valid and commonly used in linked list definitions. Step-by-Step Solution: Step 1: Notice that struct employee is introduced in the typedef line, which forward declares the struct tag. Step 2: Understand that at this point struct employee is incomplete but can be the target of a pointer type. Step 3: The typedef struct employee *ptr; therefore defines ptr as "pointer to struct employee" and is valid. Step 4: In the subsequent full definition of struct employee, the member next is declared with type ptr, which is a pointer to struct employee. Step 5: Because C allows self referential structs through pointers, this pattern is both valid and idiomatic. Verification / Alternative check: Many textbooks show self referential structures using exactly this style: typedef struct node *NodePtr; struct node { int data; NodePtr next; }; The compiler accepts this because only pointers to the incomplete type are introduced before the body. If you attempt to declare a struct employee variable before the full definition, the compiler will reject sizeof and object layout, which confirms the distinction between using the tag for pointers and for complete objects. Why Other Options Are Wrong: Option B claims that the typedef must follow the full definition, which is not required by the C standard and would make many common idioms impossible. Option C suggests that this is only valid in C plus plus, but the pattern is standard C as well. Option D incorrectly states that a struct may not contain a pointer to its own type, even though this is exactly how linked lists and trees are typically defined in C. Common Pitfalls: A frequent misunderstanding is to think that any use of a struct tag before its full definition is illegal. The real rule is that incomplete types may appear in pointer declarations but not as complete object types requiring a known size. Another pitfall is confusing typedef names with new distinct types; here ptr is simply an alias for a pointer type and obeys the same rules as struct employee * in all contexts. Final Answer: Yes, it is valid in C to create a typedef for a pointer to an incomplete struct type and then use that typedef inside the struct definition for self referential pointer members.

Question 16

In C, how can you improve the following linked node declaration and allocation code using typedef so that the type name is shorter and clearer?  struct node {     int   data1;     float data2;     struct node *left;     struct node *right; };  struc…

Accepted Answer

Introduction / Context: C code that uses struct types can become verbose when the keyword struct is repeated many times, especially in pointer declarations and dynamic allocations. The typedef feature allows you to create a shorter alias for a struct type, which improves readability for frequently used structures such as linked nodes. This question asks you to select the version of the code that uses typedef in a clean and idiomatic way when declaring and allocating a node pointer. Given Data / Assumptions: The original definition uses struct node and struct node pointers for left and right children. ptr is intended to be a pointer to the node type. Dynamic allocation is done using malloc with the desired object size. We aim to introduce a typedef without breaking the structure or pointer semantics. Concept / Approach: A standard way to simplify usage is to keep the struct tag for debugging or forward declarations and create a typedef name that refers to the complete struct. The typedef can appear immediately after the struct definition: typedef struct node { fields } Node;. From that point on, Node is a synonym for struct node, and pointers can be written as Node *ptr; instead of struct node *ptr;. For allocation, it is safer and clearer to use sizeof(Node) or sizeof *ptr so that changes to the type are automatically reflected in the allocation size. Step-by-Step Solution: Step 1: Keep the struct node definition with its tag, because the left and right pointers use struct node * as their type. Step 2: Introduce a typedef that names this type Node, as in } Node; at the end of the definition. Step 3: Declare the pointer ptr using the new alias: Node *ptr; which is equivalent to struct node *ptr;. Step 4: Allocate memory using malloc(sizeof(Node)); so that the allocation matches the full size of the struct. Step 5: Choose the option that implements exactly this pattern without changing the structure layout or pointer types. Verification / Alternative check: You can verify equivalence by noting that Node and struct node refer to the same type. Any function that previously took struct node * can now be rewritten to use Node * without changing compiled behaviour. Using sizeof(Node) and sizeof(struct node) yields the same size. This confirms that the chosen refactoring is purely syntactic, improving readability while preserving semantics. Why Other Options Are Wrong: Option B introduces the typedef but continues to use struct node *ptr and sizeof(struct node), which misses the opportunity to simplify declarations. Option C defines an anonymous struct and incorrectly declares ptr as a plain Node rather than a pointer, making the malloc call invalid. Option D declares Node as an alias before the struct is defined and misuses Node as a non pointer object, which does not match the original pointer based design. Common Pitfalls: A common error is to drop the struct tag entirely and then accidentally refer to struct node elsewhere, causing compilation errors. Another pitfall is to mismatch pointer and non pointer types, for example allocating with malloc for one Node but assigning to a Node rather than Node * pointer. When refactoring with typedef, always ensure that the alias represents the full structure and that pointers are declared explicitly where needed. Final Answer: The improved code defines typedef struct node { ... } Node; and then uses Node *ptr = malloc(sizeof(Node)); so that Node becomes a convenient alias for struct node.

Question 17

In C, how would you dynamically allocate a 2 dimensional array of integers with ROWS rows and COLS columns using pointers and malloc, so that you can access elements as arr[i][j]?

Accepted Answer

Introduction / Context: Many C programs need to allocate two dimensional arrays at run time when the number of rows and columns is not known at compile time. This question examines how to correctly allocate such a structure using a pointer to pointer approach so that elements can be accessed with the familiar arr[i][j] syntax. It also highlights common mistakes made when mixing dynamic allocation with multi dimensional indexing. Given Data / Assumptions: The number of rows is ROWS and the number of columns is COLS, determined at run time. We want to access elements as arr[i][j] where 0 ≤ i < ROWS and 0 ≤ j < COLS. We will use malloc for dynamic allocation and int as the element type. The solution should be portable and standards compliant C. Concept / Approach: One common dynamic allocation pattern uses a pointer to pointer int arr. The first allocation reserves ROWS pointers to rows. Each pointer arr[i] then points to a dynamically allocated block of COLS integers. This layout matches the type int and allows arr[i][j] to work, because arr[i] is an int * and arr[i][j] indexes element j within that row. The sizeof operator should be written in a way that does not repeat the type, using sizeof *arr for row pointers and sizeof *arr[i] for row elements. Step-by-Step Solution: Step 1: Declare a double pointer: int arr;. Step 2: Allocate memory for ROWS row pointers using arr = malloc(ROWS * sizeof *arr);. Step 3: For each i from 0 to ROWS - 1, allocate a row using arr[i] = malloc(COLS * sizeof *arr[i]);. Step 4: After these allocations, arr[i] is a valid pointer to COLS integers, so arr[i][j] is legal for all valid indices. Step 5: Remember that later you must free each arr[i] and then free arr to avoid memory leaks. Verification / Alternative check: You can reason about the types: arr has type int , so arr[i] has type int *. That pointer can be passed to functions expecting an array of int, and the expression arr[i][j] is defined as *(arr[i] + j), which is valid because arr[i] points to a block of COLS ints. This confirms that the allocation matches the intended usage. The sizeof *arr idiom further protects the code if the type of arr ever changes. Why Other Options Are Wrong: Option B allocates a single flat block but then incorrectly treats arr as if it were int and tries to index arr[i], which is invalid because arr points to int, not to int *. Option C uses calloc with the wrong total size and still leaves arr uninitialised as a set of pointers, so arr[i][j] is not meaningful. Option D declares a fixed size array with automatic storage duration, which is not dynamic allocation and does not use malloc at all. Common Pitfalls: A common mistake is to allocate ROWS * COLS integers and assign that address directly to int arr, which breaks the two level pointer model required for arr[i][j]. Another pitfall is to use sizeof(int *) instead of sizeof *arr when allocating row pointers, which can be correct but is more error prone. Always align your allocation pattern with the pointer types you actually use in indexing expressions. Final Answer: The correct pattern is int arr = malloc(ROWS * sizeof *arr); followed by a loop that assigns arr[i] = malloc(COLS * sizeof *arr[i]); so that arr[i][j] can be used safely.

Question 18

In the following C program, dynamic memory is allocated for a 2 dimensional array using a double pointer. How should you correctly free all allocated memory to avoid leaks?  #include "alloc.h" #define MAXROW 3 #define MAXCOL 4  int main(void) {     …

Accepted Answer

Introduction / Context: Correctly freeing dynamically allocated memory is just as important as allocating it. When a two dimensional structure is built using a pointer to pointer pattern, each allocation must be paired with a corresponding free call. This question checks whether you understand the lifetime of both the array of row pointers and the rows themselves, and whether you know the correct order in which to release them. Given Data / Assumptions: p is an int allocated with malloc(MAXROW * sizeof(int *)). For each i from 0 to MAXROW - 1, p[i] points to a dynamically allocated array of MAXCOL ints. No other pointers reference these blocks, so freeing through p is sufficient. The system does not automatically free malloc allocated memory until the process terminates. Concept / Approach: Memory must be freed in the reverse order of allocation so that you never dereference freed pointers. Each p[i] points to a distinct block of MAXCOL ints, so you must call free on each p[i] to release those row blocks. After all row blocks are freed, the array of pointers itself (pointed to by p) can be freed. At that point, there are no remaining valid p[i] entries, so iterating over them after freeing p would be invalid. Step-by-Step Solution: Step 1: Recognise that p points to an array of MAXROW pointers, and each p[i] points to an array of MAXCOL ints. Step 2: To free the row blocks, write a loop for (i = 0; i Step 3: After this loop, all int arrays have been returned to the heap, but p itself still points to the array of pointers. Step 4: Call free(p); to release the memory for the pointer array. Step 5: Optionally set p to NULL after freeing if it will be used later in the function, to avoid accidental dereference. Verification / Alternative check: Counting allocations confirms the approach. There is one allocation for p and MAXROW allocations for each row. Therefore there must be MAXROW + 1 free calls, one for each block. If you track memory with a tool such as valgrind in a similar example, you will see that freeing each p[i] and then p eliminates all leaks. Freeing p first would lose the addresses needed to free the rows, demonstrating why order matters. Why Other Options Are Wrong: Option B calls free(p) before free(p[i]), which is incorrect because after freeing p, the pointer array is invalid and dereferencing p[i] is undefined behaviour. Option C frees only p[0] and p, leaking the other row allocations. Option D claims that nothing needs to be freed, which is wrong for long running applications and contradicts the design of malloc and free in C, where the programmer is responsible for deallocation. Common Pitfalls: Programmers sometimes free only the top level pointer and forget to free nested allocations, leading to memory leaks that may accumulate over time. Another pitfall is double freeing the same pointer or freeing in the wrong order, which can corrupt the heap. Always match each malloc call with exactly one free and free nested allocations from the leaves upwards. Final Answer: You must free each row with for (i = 0; i < MAXROW; i++) free(p[i]); and then free the array of pointers itself with free(p); to correctly release all memory.

Question 19

In C dynamic memory management, can you increase the size of a dynamically allocated array, and if yes, which standard library function is typically used and how should it be applied safely?

Accepted Answer

Introduction / Context: Arrays allocated with malloc often need to grow or shrink as data structures change size at run time. The C standard library provides a specific function, realloc, to support resizing previously allocated blocks while preserving their existing contents when possible. This question asks whether such resizing is legal and how to use realloc safely in idiomatic C code. Given Data / Assumptions: An existing heap allocated block was created with malloc, calloc or realloc and is referenced by a pointer p. You now need space for newCount elements of the same type. You wish to keep existing elements and extend the block if possible. Error handling for allocation failure should be considered. Concept / Approach: The realloc function takes a pointer to an existing block and a new size in bytes. It may either extend the block in place or allocate a new block, copy the old contents up to the minimum of old and new sizes and then free the old block. If the requested size is zero, realloc may behave like free. Because realloc can return NULL on failure without freeing the original block, it is safer to assign its result to a temporary pointer, check for success, and only then update the original pointer variable. Step-by-Step Solution: Step 1: Compute the new size in bytes as newCount * sizeof *p for an array of the same element type. Step 2: Call realloc using a temporary pointer: int *tmp = realloc(p, newCount * sizeof *p);. Step 3: Check whether tmp is not NULL. If it is NULL, the reallocation failed and p still points to the original block. Step 4: If tmp is non NULL, assign p = tmp; so that p now points to the resized block. Step 5: Continue to use p as before, remembering to free it exactly once when it is no longer needed. Verification / Alternative check: The C standard specifies that if realloc fails, it returns NULL and leaves the original block untouched, which is why overwriting p directly would lose the pointer and leak memory. Testing in small programs shows that reallocation can often grow arrays without copying if there is space, or else returns a new pointer with preserved contents. This confirms that realloc is the intended mechanism for dynamically resizing arrays in C. Why Other Options Are Wrong: Option B is incorrect because realloc is specifically designed to change the size of a dynamically allocated block. Option C suggests that changing the pointer value directly can grow memory, which has no basis in the C runtime and leads to undefined behaviour. Option D frees and reallocates without copying, which loses all existing data and therefore does not match the usual requirement when increasing array size. Common Pitfalls: A common mistake is to write p = realloc(p, newSize); without checking for failure. If realloc returns NULL, the original block is leaked because its address has been overwritten. Another pitfall is to allocate the wrong number of bytes by forgetting to multiply by sizeof element, leading to buffer overflows or wasted memory. Using sizeof *p and a temporary pointer pattern reduces these risks in real applications and exam answers. Final Answer: Yes, you can grow a dynamically allocated array by calling realloc, for example int *tmp = realloc(p, newCount * sizeof *p); and if tmp is not NULL, then assigning p = tmp;.

Question 20

In C dynamic memory allocation, what is the main difference between malloc() and calloc() functions when allocating blocks from the heap?

Accepted Answer

Introduction / Context: The C standard library provides several functions for allocating heap memory, and understanding the differences between them is important for writing correct and efficient programs. malloc and calloc are two commonly used functions that appear similar but behave differently in terms of how they compute the allocation size and how they initialise the allocated block. This question asks you to recall their key distinctions. Given Data / Assumptions: malloc takes one argument, the total size in bytes. calloc takes two arguments, the number of elements and the size of each element. Both functions return a void * pointer on success or NULL on failure. We are concerned with initialisation state as well as parameter meaning. Concept / Approach: malloc(size) simply reserves a block of at least size bytes and leaves its contents indeterminate; the bytes may contain leftover data from previous uses of that memory region. It is the programmer's responsibility to initialise the memory before use. calloc(n, size) computes n * size bytes and then allocates that block, setting all bits in the memory region to zero. For integer and pointer types, that effectively means values are zero or NULL. For floating point and more complex types, bitwise zero is usually but not always the same as numerical zero, but in practice it is treated that way on common platforms. Step-by-Step Solution: Step 1: Describe malloc: it has the prototype void *malloc(size_t size) and returns uninitialised memory. Step 2: Describe calloc: it has the prototype void *calloc(size_t n, size_t size) and returns memory where all bytes have been set to zero. Step 3: Recognise that calloc internally multiplies n by size to determine the total number of bytes requested. Step 4: Note that both functions require error checking for NULL return values and that the returned memory must eventually be freed with free. Step 5: Choose the option that mentions both the uninitialised versus zero initialised behaviour and the parameter difference. Verification / Alternative check: You can test the difference by allocating an array of int with malloc and printing its contents; you will likely see unpredictable values. With calloc, the same experiment typically prints zeros. Documentation for C libraries emphasises that calloc performs an initialisation step equivalent to memset to zero, whereas malloc does not. This confirms the explanation and clarifies that both allocate on the heap, not on the stack. Why Other Options Are Wrong: Option B incorrectly claims that malloc allocates on the stack, which is not true; stack storage is controlled by automatic variables, not malloc. Option C states that calloc always succeeds, which is false; both functions can fail if memory is exhausted. Option D denies any difference, ignoring the distinct parameter lists and the important initialisation behaviour of calloc. Common Pitfalls: One pitfall is to rely on malloc to provide zeroed memory, which can lead to subtle bugs when uninitialised values are used. Another is to forget that calloc's multiplication of n and size can overflow size_t, potentially resulting in a smaller allocation than expected. In performance critical code, programmers sometimes prefer malloc plus explicit initialisation to avoid the overhead of zeroing large blocks when not necessary. Final Answer: malloc(size) allocates an uninitialised block of size bytes, while calloc(n, size) allocates space for n elements of the given size and sets all bits in the allocated block to zero.

Programming Questions

Questions

Practice smarter