Question 1

Pointer increments and self-referential structures in C (Turbo C under DOS): predict the output of this program.  #include<stdio.h>  int main() {  struct s1 {  char *z;  int i;  struct s1 *p;  };   static struct s1 a[] = {  {"Nagpur", 1, a+1},  {"Ch…

Accepted Answer

Introduction / Context: This exercises pointer arithmetic on strings, pre-increment/decrement operators, and navigation through a self-referential array of structures. It is a classic test of sequence points and evaluation in C under Turbo C, but the logic is standard C. Given Data / Assumptions: a[0] = {"Nagpur", 1, a+1} a[1] = {"Chennai", 2, a+2} a[2] = {"Bangalore", 3, a} ptr initially points to a[0]. Concept / Approach: Understand that ++(ptr->z) increments the char inside a[0]; (++ptr)->i increments the struct pointer before indexing; and --(ptr->p->i) decrements the i field inside a[2] through the link from a[1]. Step-by-Step Solution: 1) ++(ptr->z): "Nagpur" becomes pointer to "agpur" ⇒ prints "agpur,".2) (++ptr) moves ptr to a[1]; ptr->i is 2 ⇒ a[2].z = "Bangalore" ⇒ prints " Bangalore,".3) ptr->p is a+2; (ptr->p->i) is 3; pre-decrement makes it 2; a[2].z still "Bangalore" ⇒ prints " Bangalore". Verification / Alternative check: Instrument the code to print intermediate addresses and i values to verify pointer movement and decrement. Why Other Options Are Wrong: Option A: Fails to account for the ++ on z and the decremented index. Option B/C: Mis-handle either the city names or the indices affected by pre-operators. Common Pitfalls: Forgetting that ++ on a pointer advances the string, and that -- applies to i inside the targeted struct, not the array index expression value alone. Final Answer: agpur, Bangalore, Bangalore

Question 2

Casting chain and sizeof result in Turbo C (DOS): what is printed here?  #include<stdio.h> double i;  int main() {  (int)(float)(char) i; // value unused; type chain matters  printf("%d", sizeof((int)(float)(char)i));  return 0; }

Accepted Answer

Introduction / Context: The expression casts i through char, then float, then int, and sizeof is applied to the resulting type. In Turbo C (16-bit DOS), int is typically 2 bytes. Given Data / Assumptions: sizeof(int) = 2 bytes on Turbo C 16-bit. sizeof is computed at compile time based on the expression type after casts. Concept / Approach: The final cast determines the sizeof result. Intermediate casts do not matter for sizeof once the final type is known. Step-by-Step Solution: 1) (char)i yields type char.2) (float)(char)i yields type float.3) (int)(float)(char)i yields type int.4) sizeof(int) on Turbo C is 2 ⇒ the program prints 2. Verification / Alternative check: Print sizeof(int) directly to confirm 2 on the target toolchain. Why Other Options Are Wrong: Options C/D assume 32-/64-bit sizes not applicable to Turbo C; Option A confuses char size with the final cast. Common Pitfalls: Believing that the value of i or intermediate types influence sizeof once the final cast is int. Final Answer: 2

Question 3

Turbo C (DOS): mix of near/far/huge with sizeof at different dereference depths — what is printed?  #include<stdio.h>  int main() {  char huge *near *far *ptr1;  char near *far huge ptr2;  char far huge near ptr3;  printf("%d, %d, %d ", sizeof(ptr1)…

Accepted Answer

Introduction / Context: This problem explores how dereferencing exposes the next pointer level's qualifier, which then determines sizeof for that expression in Turbo C. It is about careful parsing, not arithmetic. Given Data / Assumptions: near = 2 bytes; far = 4 bytes; huge = 4 bytes. ptr1 is far to (near to (huge to char)). ptr2 is huge; ptr3 is near to (huge to (far to char)). Concept / Approach: Each dereference moves one level inward: ptr1 reaches a huge; ptr2 is itself huge; ptr3 is huge. sizeof of any huge under Turbo C is 4. Step-by-Step Solution: 1) **ptr1 ⇒ huge * ⇒ sizeof(**ptr1) = 4.2) ptr2 ⇒ huge * ⇒ sizeof(ptr2) = 4.3) *ptr3 ⇒ huge * ⇒ sizeof(*ptr3) = 4.4) Output: 4, 4, 4. Verification / Alternative check: Break the types with typedefs for readability and print sizeof each alias. Why Other Options Are Wrong: Option B: Treats all as near; Option C/D: Inject impossible 8-byte sizes or wrong bindings. Common Pitfalls: Forgetting that dereferencing does not necessarily reach the base char; at each step you may still be at a pointer type with its own qualifier. Final Answer: 4, 4, 4

Question 4

C on 16-bit DOS (Turbo C): what will this program print, and why does the cast chain not matter?  #include<stdio.h>  double i;  int main() {  (int)(float)(char) i; // no effect on i or sizeof  printf("%d", sizeof(i));  return 0; }

Accepted Answer

Introduction / Context: This question tests understanding of C's sizeof operator and the effect (or lack of effect) of cast expressions that are not used. In classic 16-bit DOS compilers like Turbo C, the size of fundamental types can differ from today’s 32/64-bit compilers. Here, we focus on what actually gets printed and why the cast chain does not change the result. Given Data / Assumptions: Environment: Turbo C on DOS (16-bit). Global variable: double i; Prints: printf("%d", sizeof(i)); There is a cast chain (int)(float)(char) i; whose value is not used. Concept / Approach: The sizeof operator returns the size, in bytes, of its operand’s type at compile time. Unused cast expressions are evaluated only for their value category/type (and may be optimized away); they do not change the type or size of the declared object. On Turbo C, sizeof(double) is typically 8 bytes. Step-by-Step Solution: 1) Identify the printed expression: sizeof(i) equals sizeof(double). 2) On Turbo C (16-bit), sizeof(double) is 8. 3) The cast chain forms a temporary value and is discarded; it does not alter i. 4) Therefore, the program prints 8. Verification / Alternative check: Remove the cast line entirely; the output remains the same because sizeof(i) depends only on i’s type, not on prior unused expressions. Why Other Options Are Wrong: 4: On Turbo C, double is not 4 bytes. 16/22: These sizes do not match Turbo C's double. 0: sizeof never returns zero for an object type. Common Pitfalls: Assuming sizeof(double) is always the host’s modern 8/16 bytes; conflating type conversions with object size; believing that an unused cast changes the variable’s type. Final Answer: 8

Complicated Declarations Questions