Question 1

C memory lifetime — what is printed when returning a pointer to a local array? /* program */ #include #include int main() { char *s; char *fun(); s = fun(); printf("%s ", s); return 0; } char fun() { char buffer[30]; str…

Accepted Answer

Introduction / Context: This question targets understanding of object lifetime and undefined behavior in C when returning addresses of automatic (stack) variables. It checks whether the learner recognizes that local arrays cease to exist once the function returns. Given Data / Assumptions: buffer is a local char array in fun with automatic storage duration. fun returns buffer's address to main. main then prints the string at that stale address. Concept / Approach: Once fun returns, buffer's lifetime ends and the pointer value points to indeterminate storage. Accessing it (reading through it in printf("%s", s)) is undefined behavior and may display arbitrary data, crash, or appear to work by chance. There is no guaranteed, portable output. Step-by-Step Solution: 1) buffer[30] is created on the stack inside fun.2) After return, the stack frame is invalidated; buffer no longer exists.3) s in main holds an invalid/dangling pointer.4) printf reads memory via s, producing unpredictable characters or behavior. Verification / Alternative check: Correct fixes include making buffer static (static char buffer[30];) or allocating with malloc and returning the allocated pointer, then freeing it in main. Either approach gives a defined lifetime beyond fun's return. Why Other Options Are Wrong: Specific hex addresses (0xffff, 0xffee): These are arbitrary guesses; output is not a fixed address string. Error: Most compilers only warn; the code often still compiles. Common Pitfalls: Assuming a successful run implies correct code. Undefined behavior may seem to work during tests, masking serious bugs. Final Answer: Garbage value

Question 2

C dynamic allocation — how many bytes are reserved by this call? #include #include int main() { int p; p = (int ) malloc(256 * 256); if (p == NULL) printf("Allocation failed"); return 0; } Assume the request succeeds. How …

Accepted Answer

Introduction / Context: This problem checks if you can compute the size argument passed to malloc and interpret it as bytes reserved, independent of the pointer's base type. The cast to int does not change the number of bytes requested. Given Data / Assumptions: malloc is called with 256 * 256. No sizeof is involved in the multiplication. We assume the allocation succeeds for the purpose of counting bytes. Concept / Approach: malloc receives a size in bytes. The expression 256 * 256 equals 65536, so malloc attempts to reserve exactly 65536 bytes. The type of p (int) only affects how you interpret the memory later, not the number of bytes allocated. Step-by-Step Solution: 1) Compute size = 256 * 256 = 65536.2) malloc requests that many bytes from the heap.3) p points to the first byte of the reserved block (cast to int*). Verification / Alternative check: To reserve space for N ints portably, use malloc(N * sizeof *p). Here the code requests a raw byte count; counting bytes confirms the value 65536. Why Other Options Are Wrong: Allocation failed / Error / No output: These describe runtime outcomes, not the byte count requested by the code. Common Pitfalls: Confusing number of elements with number of bytes or assuming sizeof(int) is implicitly applied. Always multiply by sizeof when allocating typed arrays. Final Answer: 65536

Question 3

C unions — what is printed after storing a float in a union and reading it back? #include #include int main() { union test { int i; float f; char c; }; union test *t = (union test *) malloc(sizeof(union test)); t->f = 10…

Accepted Answer

Introduction / Context: This question focuses on unions in C and accessing the same member that was most recently written. It checks whether learners understand that reading back the same active member yields the stored value, subject to normal floating-point formatting in printf. Given Data / Assumptions: t points to a valid union test object. t->f is assigned 10.10f. printf uses "%f" to print a float (promoted to double on call). Concept / Approach: If you write to one member of a union and then read the same member, you get the stored value. Using a different member without writing it is not meaningful. printf("%f") will display the value with default precision (typically 6 places after the decimal), so 10.10f prints as 10.100000 by default. Step-by-Step Solution: 1) Allocate union test; assignment to t->f sets the union's active member to float.2) Printing the same member t->f is defined behavior.3) printf formats the float as a fixed-point string with 6 decimals. Verification / Alternative check: Formatting can be changed using "%.2f" to print "10.10". With the default "%f", expect "10.100000". Why Other Options Are Wrong: 10: Not the default "%f" precision. Garbage value: Would occur only if reading a different member than written. Error: The code is valid if malloc succeeds. Common Pitfalls: Assuming unions always cause aliasing issues; here the same member is consistently used, which is fine. Final Answer: 10.100000

Question 4

C on a 16-bit platform — what does sizeof(p) print for an int* allocated with malloc? #include #include int main() { int p = (int ) malloc(20); printf("%d ", (int) sizeof(p)); free(p); return 0; } Assume a classic 16-bit me…

Accepted Answer

Introduction / Context: This problem tests platform awareness: sizeof on a pointer reports the size of the pointer type itself, which varies by architecture and memory model. On classic 16-bit DOS small/medium models, data pointers are near (2 bytes). Given Data / Assumptions: Target is a 16-bit environment like Turbo C small/medium model. p is declared as int (a data pointer). sizeof(p) is evaluated and printed as an int. Concept / Approach: sizeof(p) depends only on the pointer type, not on the allocated size. On many 16-bit compilers, near data pointers are 2 bytes. Therefore sizeof(int) is 2 in those models. (Far/huge models may differ, but the question specifies a 16-bit platform context where 2 is the canonical teaching answer.) Step-by-Step Solution: 1) Identify pointer category: near data pointer.2) On 16-bit near model, sizeof pointer = 2 bytes.3) Hence the program prints 2. Verification / Alternative check: Switching to a 32-bit or 64-bit compiler typically yields 4 or 8 respectively for sizeof(void*) and data pointers, confirming the platform dependence. Why Other Options Are Wrong: 4/8: Sizes found on 32/64-bit systems, not classic 16-bit near model. Garbage value: sizeof is compile-time and deterministic. Common Pitfalls: Confusing allocated block size with pointer size. sizeof(p) is not related to malloc(20). Final Answer: 2

Question 5

C after free — what does printing the pointer value show? #include #include int main() { int *p; p = (int ) malloc(20); / Assume, for illustration, p held address 1314 / free(p); printf("%u", p); / Printing pointer with %u i…

Accepted Answer

Introduction / Context: This question examines behavior after freeing dynamically allocated memory. It also highlights that printing pointers with %u is non-portable (the correct specifier is %p). The central concept is undefined behavior and dangling pointers. Given Data / Assumptions: p is freed using free(p). The code then prints p's value with %u. Assumed pre-free value 1314 is for illustration only. Concept / Approach: After free, p becomes a dangling pointer: its stored bits may remain the same, but using it is undefined behavior. Even reading or printing it in a non-portable manner can produce unpredictable results. Therefore, you cannot rely on seeing 1314 or any specific value. The robust practice is to set p = NULL after free and print with %p if needed. Step-by-Step Solution: 1) Memory is released; p is not automatically nullified.2) Using p's value post-free is undefined; even printing it is not meaningful.3) Output may vary by run, compiler, and optimization. Verification / Alternative check: Setting p = NULL after free and then printing with printf("%p", (void)p) yields a consistent "(nil)" style representation on many systems, demonstrating defined behavior. Why Other Options Are Wrong: 1314/1316: Suggests a deterministic address; not guaranteed. Random address: While colloquially similar, "Garbage value" better reflects UB in MCQ context. Common Pitfalls: Believing that free changes the pointer value or that printing a freed pointer is safe. Always invalidate the pointer explicitly. Final Answer: Garbage value

Question 6

C pointers to arrays — sizes when int is 2 bytes. #include #include #define MAXROW 3 #define MAXCOL 4 int main() { int (p)[MAXCOL]; p = (int ()[MAXCOL]) malloc(MAXROW * sizeof(*p)); printf("%d, %d ", (int) sizeof(p), (int) si…

Accepted Answer

Introduction / Context: This question evaluates understanding of pointers to arrays and the difference between the size of a pointer and the size of the pointed-to object. The result depends on platform pointer size and known array dimensions. Given Data / Assumptions: sizeof(int) = 2 bytes. p has type pointer to array of MAXCOL (4) ints. Classic 16-bit near data pointer size of 2 bytes is assumed. Concept / Approach: sizeof(p) is the size of the pointer itself (near pointer, 2 bytes). sizeof(*p) is the size of the array it points to, which is 4 * sizeof(int) = 4 * 2 = 8 bytes. The malloc line allocates MAXROW arrays of 4 ints, but the printf only asks for the two sizes. Step-by-Step Solution: 1) sizeof(p) = size of a near data pointer = 2.2) sizeof(*p) = size of int[4] = 4 * 2 = 8.3) Printed output therefore is "2, 8". Verification / Alternative check: On 32-bit systems, the first value would typically be 4, and on 64-bit systems 8, confirming platform dependence for pointer size only. Why Other Options Are Wrong: 4, 16 / 8, 24 / 16, 32: These correspond to different pointer sizes or wrong array-size calculations. Common Pitfalls: Confusing sizeof(p) with the size of allocated memory or forgetting that *p is an entire array, not a single int. Final Answer: 2, 8

Question 7

C pointer-to-array allocation — total bytes allocated when int is 2 bytes. #include #include #define MAXROW 3 #define MAXCOL 4 int main() { int (p)[MAXCOL]; p = (int ()[MAXCOL]) malloc(MAXROW * sizeof(*p)); return 0; } Assum…

Accepted Answer

Introduction / Context: This problem tests computing total bytes allocated when using a pointer to an array type with malloc. It reinforces that sizeof(*p) represents the entire array object, not just a single element. Given Data / Assumptions: sizeof(int) = 2 bytes. *p has type int[4]. We allocate MAXROW (3) blocks of type *p. Concept / Approach: sizeof(*p) = number_of_columns * sizeof(int) = 4 * 2 = 8 bytes. The malloc call requests MAXROW * sizeof(*p) = 3 * 8 = 24 bytes. The pointer type or casting does not change the size requested. Step-by-Step Solution: 1) Determine size of one row: 4 ints * 2 bytes = 8 bytes.2) Multiply by number of rows: 3 * 8 = 24.3) malloc requests 24 bytes in total. Verification / Alternative check: Printing sizeof(*p) in code (as in the previous question) yields 8, confirming the per-row size. Multiplying by 3 confirms 24. Why Other Options Are Wrong: 56/128: Overestimates unrelated to the given dimensions. 12: Would be 3 * 4, incorrectly using sizeof(int) instead of sizeof(*p). Common Pitfalls: Forgetting that *p is an entire array type and miscounting bytes by element instead of by row. Final Answer: 24 bytes

Memory Allocation Questions