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 + 1) using %u (treating them as unsigned addresses)? #include<stdio.h> int main() { int a[3][4] = {1, 2, 3, 4, 4, 3, 2, 1, 7, 8, 9, 0}; printf("%u, %u\n", a+1, &a+1); return 0; }

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:

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