Q: Predict the output in Turbo C (16-bit DOS environment): #include int main() { int arr[5], i = 0; while(i < 5) arr[i] = ++i; for(i = 0; i < 5; i++) printf("%d, ", arr[i]); return 0; }

Introduction / Context: Understanding pre-increment (++i) inside assignments and how it interacts with loop control is a foundational C topic. This program fills an array while incrementing the index. Given Data / Assumptions: arr has 5 elements. i starts at 0; the loop condition is i < 5. The assignment arr[i] = ++i uses pre-increment. Concept / Approach: With pre-increment, ++i increments i first, then the incremented value is used. Because the index in arr[i] is evaluated before ++i changes i, the assignment stores values 1..5 into arr[0..4] respectively as the loop advances. Step-by-Step Solution: Start i=0: condition true → arr[0] = ++i → i=1; arr[0]=1.Next: i=1: arr[1] = ++i → i=2; arr[1]=2.Repeat until i=4: arr[4] = ++i → i=5; arr[4]=5.Loop ends when i becomes 5; printing yields 1, 2, 3, 4, 5,. Verification / Alternative check: Change to arr[i++] = i; and observe a different sequence; or use explicit increments to trace values. Why Other Options Are Wrong: They assume post-increment behavior or initial garbage values. There is no syntax error. Common Pitfalls: Confusing arr[i] = ++i with arr[++i] = i; mixing pre vs post increment side effects. Final Answer: 1, 2, 3, 4, 5,

Q: In C, when printing the addresses of an array and its first element on a typical system conceptually viewed with 2-byte ints, suppose the array arr begins at address 1200. What values are printed for arr, &arr[0], and &arr using %u? #include<stdio.…

Introduction / Context: This problem reinforces that an array name decays to the address of its first element in expressions, and that &arr gives the same numeric base address but has a different pointer type (pointer to the entire array). Given Data / Assumptions: arr starts at numeric address 1200. arr is int arr[5] with conceptual 2-byte ints for address arithmetic context. We print arr, &arr[0], and &arr using %u (just numeric addresses). Concept / Approach: In C, arr (in most expressions) decays to &arr[0]. Therefore arr and &arr[0] point to the same location numerically. The expression &arr has type pointer-to-array-of-5-ints, but it still points to the same starting address numerically. Step-by-Step Solution: arr -> address of first element = 1200 &arr[0] -> also 1200 &arr -> address of whole array = same numeric base 1200 Verification / Alternative check: Dereferencing levels differ: *arr is int, while *&arr is the whole array. Yet the base numeric address stored is identical, so printing with %u shows 1200 for all three. Why Other Options Are Wrong: 1200, 1202, 1204 and 1200, 1204, 1208: Assume increments without actually incrementing pointers. 1200, 1202, 1200: Invents a 2-byte offset for &arr[0] even though no arithmetic was done. Common Pitfalls: Confusing pointer type with numeric address value. Type affects arithmetic step size, not the base numeric address printed here. Final Answer: 1200, 1200, 1200

Question 1

Predict the output in Turbo C (16-bit DOS environment): #include<stdio.h>  int main() {  int arr[5], i = 0;  while(i < 5)  arr[i] = ++i;   for(i = 0; i < 5; i++)  printf("%d, ", arr[i]);   return 0; }

Accepted Answer

Introduction / Context: Understanding pre-increment (++i) inside assignments and how it interacts with loop control is a foundational C topic. This program fills an array while incrementing the index. Given Data / Assumptions: arr has 5 elements. i starts at 0; the loop condition is i < 5. The assignment arr[i] = ++i uses pre-increment. Concept / Approach: With pre-increment, ++i increments i first, then the incremented value is used. Because the index in arr[i] is evaluated before ++i changes i, the assignment stores values 1..5 into arr[0..4] respectively as the loop advances. Step-by-Step Solution: Start i=0: condition true → arr[0] = ++i → i=1; arr[0]=1.Next: i=1: arr[1] = ++i → i=2; arr[1]=2.Repeat until i=4: arr[4] = ++i → i=5; arr[4]=5.Loop ends when i becomes 5; printing yields 1, 2, 3, 4, 5,. Verification / Alternative check: Change to arr[i++] = i; and observe a different sequence; or use explicit increments to trace values. Why Other Options Are Wrong: They assume post-increment behavior or initial garbage values. There is no syntax error. Common Pitfalls: Confusing arr[i] = ++i with arr[++i] = i; mixing pre vs post increment side effects. Final Answer: 1, 2, 3, 4, 5,

Question 2

Double indirection and 2D array decay: What value prints? #include<stdio.h> void fun(int **p);  int main() {  int a[3][4] = {1, 2, 3, 4, 4, 3, 2, 8, 7, 8, 9, 0};  int *ptr;  ptr = &a[0][0];  fun(&ptr);  return 0; } void fun(int **p) {  printf("%d ",…

Accepted Answer

Introduction / Context: This item tests decay of a 2D array to a pointer to its first element and correct use of double indirection when passing a pointer by reference to a function. Given Data / Assumptions: a is a 3x4 int matrix initialized row-major. ptr is set to &a[0][0], the address of the first element. fun receives &ptr, i.e., a pointer to an int (type int *). Concept / Approach: Inside fun, parameter p points to ptr; dereferencing once yields the original int; dereferencing twice yields the int value stored at that location. Since ptr points to the first element of a, **p is a[0][0] which equals 1. Step-by-Step Solution: ptr = &a[0][0] → ptr holds address of the first integer.fun(&ptr) passes the address of ptr.In fun, *p == ptr and *p == ptr == a[0][0] == 1. Verification / Alternative check: Change initialization so a[0][0] has a distinct value to confirm the print reflects that element; or print p, p to inspect addresses. Why Other Options Are Wrong: They assume access to other elements; the code never offsets ptr before printing. Common Pitfalls: Confusing type int ()[4] (pointer to array) with int; here we explicitly take &a[0][0] to get an int. Final Answer: 1

Question 3

In C language on a 16-bit system where each int occupies 2 bytes, consider the following 2D array a with 3 rows and 4 columns. If the base address of the array a begins at 65472 in memory, what numeric addresses will be printed for (a + 1) and (&a +…

Accepted Answer

Introduction / Context: This C pointer-arithmetic question checks how array types decay to pointers and how pointer increments depend on the pointed-to type size. It specifically contrasts a+1 (pointer to the next row) with &a+1 (pointer to the next whole array) on a 16-bit-style assumption where int is 2 bytes and the array base address is fixed for calculation. Given Data / Assumptions: a is int a[3][4]. sizeof(int) = 2 bytes. Base address of a is 65472. a has 3 * 4 = 12 ints total. Concept / Approach: In expressions, a (array) decays to pointer-to-first-row of type int (*)[4]. Incrementing such a pointer advances by sizeof(one row) = 4 * sizeof(int). For &a, the type is pointer to the entire array, int (*)[3][4]. Incrementing &a moves by sizeof(whole array) = 3 * 4 * sizeof(int). Step-by-Step Solution: row_size = 4 * 2 = 8 bytes array_size = 3 * 4 * 2 = 24 bytes a + 1 = 65472 + 8 = 65480 &a + 1 = 65472 + 24 = 65496 Verification / Alternative check: Visualize memory as 3 contiguous rows of 8 bytes each. Moving one row forward adds 8; moving one entire 3x4 block forward adds 24. The arithmetic matches this picture. Why Other Options Are Wrong: 65474, 65476: Adds 2 and 4 bytes, ignoring row and array sizes. 65480, 65488: Second value adds only 16, not full 24 bytes of the array. 65474, 65488: Mixed incorrect increments. Common Pitfalls: Confusing a (pointer to row) with &a (pointer to whole array), and assuming +1 always adds 1 byte rather than sizeof(pointed-type). Final Answer: 65480, 65496

Question 4

In C, when printing the addresses of an array and its first element on a typical system conceptually viewed with 2-byte ints, suppose the array arr begins at address 1200. What values are printed for arr, &arr[0], and &arr using %u?  #include<stdio.…

Accepted Answer

Introduction / Context: This problem reinforces that an array name decays to the address of its first element in expressions, and that &arr gives the same numeric base address but has a different pointer type (pointer to the entire array). Given Data / Assumptions: arr starts at numeric address 1200. arr is int arr[5] with conceptual 2-byte ints for address arithmetic context. We print arr, &arr[0], and &arr using %u (just numeric addresses). Concept / Approach: In C, arr (in most expressions) decays to &arr[0]. Therefore arr and &arr[0] point to the same location numerically. The expression &arr has type pointer-to-array-of-5-ints, but it still points to the same starting address numerically. Step-by-Step Solution: arr -> address of first element = 1200 &arr[0] -> also 1200 &arr -> address of whole array = same numeric base 1200 Verification / Alternative check: Dereferencing levels differ: *arr is int, while *&arr is the whole array. Yet the base numeric address stored is identical, so printing with %u shows 1200 for all three. Why Other Options Are Wrong: 1200, 1202, 1204 and 1200, 1204, 1208: Assume increments without actually incrementing pointers. 1200, 1202, 1200: Invents a 2-byte offset for &arr[0] even though no arithmetic was done. Common Pitfalls: Confusing pointer type with numeric address value. Type affects arithmetic step size, not the base numeric address printed here. Final Answer: 1200, 1200, 1200

Question 5

In C, evaluate the effects of pre-increment and post-increment on array elements and indices. For the array and statements below, what values are printed for i, j, and m?  #include<stdio.h> int main() { int a[5] = {5, 1, 15, 20, 25}; int i, j, m; i …

Accepted Answer

Introduction / Context: This question targets operator side effects: pre-increment (++x) vs post-increment (x++), and how these changes alter subsequent indexing into an array. Given Data / Assumptions: a = {5, 1, 15, 20, 25} so a[0]=5, a[1]=1, a[2]=15, a[3]=20, a[4]=25. i, j, m are ints. Concept / Approach: Pre-increment changes the variable then yields the incremented value. Post-increment yields the current value, then increments it. Also, using i++ as an index uses the old i for access and increments afterward. Step-by-Step Solution: Start: a[1] = 1 i = ++a[1] -> a[1] becomes 2, i = 2 j = a[1]++ -> j = 2, then a[1] becomes 3 m = a[i++] -> use i=2 to index: m = a[2] = 15, then i becomes 3 Final: i=3, j=2, m=15 Verification / Alternative check: Trace with a quick table of i and a[1] across each statement; results remain consistent with pre/post rules. Why Other Options Are Wrong: 2, 1, 15: j is not 1 because a[1] was already incremented to 2 before j = a[1]++. 1, 2, 5: i is not 1 and m is not a[1] or a[0]. 2, 3, 20: j is 2 (post), and m uses index 2 not 3 during access. Common Pitfalls: Forgetting that i++ uses the old i for indexing before incrementing, and mixing up pre vs post effects on a[1]. Final Answer: 3, 2, 15

Question 6

In C, array subscripting x[y] is defined as *(x + y). Using this property, what does the expression 0[arr] print for an array declared as int arr[1] = {10}?  #include<stdio.h> int main() { int arr[1] = {10}; printf("%d ", 0[arr]); return 0; }

Accepted Answer

Introduction / Context: This question highlights that in C the expression x[y] is syntactic sugar for *(x + y), which is commutative in terms of numeric addition, so y[x] is equivalent to x[y]. Given Data / Assumptions: arr is int arr[1] initialized to {10}. We evaluate 0[arr]. Concept / Approach: Since x[y] == *(x + y) == *(y + x), we can swap the operands in the subscript without changing the result as long as the sum points to a valid element. Step-by-Step Solution: arr[0] == *(arr + 0) 0[arr] == *(0 + arr) == *(arr + 0) *(arr + 0) is the first element value, which is 10 Verification / Alternative check: Compile-and-run thought experiment: replacing 0[arr] with arr[0] preserves meaning; both select the first element. Why Other Options Are Wrong: 1 and 0: Confuse value with indices. 6: Arbitrary number not present in the array. Common Pitfalls: Assuming x[y] must be “array name then index” by syntax rules. In C, addition is commutative, so y[x] is equally valid for access (though unconventional to read). Final Answer: 10

Arrays Questions