Question 1

What does the declaration char *arr[10]; signify in C? Explain the type and structure represented by arr in this declaration.

Accepted Answer

Introduction: C declarations can be read using precedence rules. This question probes your ability to parse a declaration that combines pointer and array syntax. Given Data / Assumptions: Declaration: char arr[10]; Standard C declarator binding rules apply. Concept / Approach: In declarators, [] binds tighter than . Therefore, arr is first an array of 10 elements, and each element has type pointer to char. Thus arr is an array (size 10) of char pointers. It is not a pointer to a single array, nor an array of chars, nor a function pointer. Step-by-Step Solution: 1) Parse inside-out: arr[10] → 'arr is an array of 10'.2) Then apply * to the element type: each element is 'pointer to char'.3) Result: arr is an array of 10 pointers to char. Verification / Alternative check: Consider typical usage: arr[i] = "hello"; Each arr[i] is of type char, pointing to the first character of a string literal or dynamically allocated buffer. Why Other Options Are Wrong: Array of function pointer: the element type would include '()()' for functions, which is not present.Array of characters: that would be char arr[10]; without a star.Pointer to array of characters: that would be char (*arr)[N]; with parentheses around *arr. Common Pitfalls: Misreading precedence or forgetting that [] binds more tightly than *. Parentheses are required to change binding if a pointer-to-array is intended. Final Answer: arr is a array of 10 character pointers.

Question 2

C declarations and pointers: interpret the following declaration int (*pf)(); What does it signify?

Accepted Answer

Introduction / Context: This question tests mastery of C declarator syntax for function pointers. Reading complex declarations correctly is essential when using callbacks, library hooks, signal handlers, and tables of operations. The declaration style can look cryptic at first, but a small set of rules lets you decode it reliably. Given Data / Assumptions: Declaration under analysis: int (*pf)(); No parameters are specified inside the parentheses, which in classic C implies an unspecified parameter list. Goal: determine exactly what pf represents. Concept / Approach: Use the clockwise spiral rule or a simple precedence rule: identifiers bind first to the closest parentheses, postfix operators like () and [] have higher precedence than unary *. In int (*pf)(); the inner parentheses force *pf to bind before (), producing a pointer-to-function rather than a function returning a pointer. The base type to the left is int, meaning the function's return type is int. Step-by-Step Solution: 1) Start at the identifier pf. 2) The nearest binding is (*pf), so pf is being dereferenced: pf is a pointer to something. 3) Next, () applies to (*pf), so that “something” is a function. 4) The type at the far left, int, is the function's return type. 5) Therefore, pf is a pointer to a function returning int. Verification / Alternative check: Compare with int *pf(); which declares a function named pf that returns int* (function returning pointer). The absence or presence of parentheses around *pf is decisive. You can also create a typedef: typedef int func_t(); then func_t *pf; makes the same meaning obvious. Why Other Options Are Wrong: pf is a pointer to function. This is incomplete because it omits the return type, which is int; the precise statement includes “return int”. pf is a function pointer. Too generic. While true in spirit, the best answer must state the return type. pf is a function of pointer variable. Nonsensical phrasing; the syntax does not declare a function of a pointer. Common Pitfalls: Confusing int (*pf)() with int *pf(). The former is a pointer to function returning int; the latter is a function returning pointer to int. Assuming empty parameter lists mean “no parameters”. In modern C, prefer using (void) to indicate no parameters explicitly. Final Answer: pf is a pointer to a function which return int

Question 3

C declarations: write a declaration for "An array of three pointers to chars" Choose the correct C syntax that matches the English statement.

Accepted Answer

Introduction / Context: Translating English descriptions into precise C declarations is a core skill for systems programming. The target phrase “an array of three pointers to chars” involves both array and pointer declarators, and it is easy to overcomplicate the syntax by adding function parentheses or extra indirection. Given Data / Assumptions: We want exactly 3 elements. Each element must be a pointer to char, that is, type char*. No functions are involved, no extra levels of pointers beyond one. Concept / Approach: Build from the inside out. The element type is “pointer to char”, written as char*. An array of 3 such elements is written by attaching [3] to the identifier: char *ptr[3]; Parentheses are not needed around the * for this simple case. Adding () would convert it into “array of pointers to functions”, which is not requested. Step-by-Step Solution: 1) Decide the element type: pointer to char ⇒ char*. 2) Make an array of 3 such elements ⇒ char *ptr[3]; 3) Confirm that ptr[i] has type char* for i in {0,1,2}. 4) No function declarators are present, so no call syntax appears. Verification / Alternative check: Use sizeof to confirm: sizeof(ptr) equals 3 * sizeof(char*). The expression *ptr[i] then has type char, confirming that each element is a pointer to char, not a function or a pointer to pointer. Why Other Options Are Wrong: char *ptr[3](); Declares an array of 3 functions returning char*, which is illegal because arrays of functions are not allowed; with some compilers it is read as array of 3 pointers to functions returning char* due to decay, which still does not match. char (*ptr[3])(); Explicitly an array of 3 pointers to functions, not pointers to char. char **ptr[3]; An array of 3 pointers to pointer to char (char**), which is one extra level of indirection. Common Pitfalls: Adding function parentheses by habit, creating function pointer declarations unintentionally. Confusing char* (pointer to char) with char** (pointer to pointer to char). Final Answer: char *ptr[3];

Question 4

C declarations: interpret the following declaration int *f(); What exactly does it mean?

Accepted Answer

Introduction / Context: Distinguishing “function returning pointer” from “pointer to function” is a frequent stumbling block in C. The position of parentheses relative to * and the identifier determines whether you declare a function or a pointer to a function. This question focuses on the declaration int *f(); Given Data / Assumptions: Declaration: int *f(); Empty parameter list means an unspecified list in old-style C. In modern code, prefer int *f(void) for no parameters. We must decide whether f itself is a pointer or a function. Concept / Approach: Operator precedence puts () on the identifier first. Because there are no parentheses around *f, the () applies to f, making f a function. The return type is int*, derived from the leading int *. Therefore, f is a function that, when called, returns a pointer to int. By contrast, a pointer to function returning int would look like int (*pf)(); Step-by-Step Solution: 1) Identify the identifier: f. 2) Postfix () binds to f, so f is a function. 3) The type to the left is int *, therefore the function's return type is pointer to int. 4) Conclude: f is a function returning pointer to int. Verification / Alternative check: Introduce a typedef for clarity: typedef int* pint; then pint f(); reads more naturally as “f returns pint”, confirming the interpretation. Another check is to compare with int (*f)(); which would be a pointer to a function returning int, clearly different. Why Other Options Are Wrong: Pointer variable of function type: Functions are not objects; you cannot have “pointer variable of function type” as phrased. The declaration does not make f a pointer variable at all. Function pointer: That would require parentheses around *f: int (*f)(); Simple declaration of pointer variable: A simple pointer variable would be int *p; with no (). Common Pitfalls: Forgetting that () binds tighter than *, making f a function here. Assuming empty parameter lists mean “no parameters” in all C dialects; use (void) in modern C when you mean no parameters. Final Answer: f is a function returning pointer to an int.

Question 5

C declarations: write a declaration for "A pointer to a function which receives an int pointer and returns a float pointer"

Accepted Answer

Introduction / Context: This problem assesses your ability to translate precise English descriptions into correct C declarations. Function pointer syntax in C can be tricky because parentheses affect binding order between the pointer declarator * and the function-call operator (). The goal is to declare a pointer to a function that accepts an int pointer as its sole parameter and returns a float pointer (that is, float). Given Data / Assumptions: We need a pointer to a function. That function's parameter type is int* (pointer to int). That function's return type is float* (pointer to float). No other qualifiers or calling conventions are involved. Concept / Approach: The pattern for a pointer to function is: return_type (*identifier)(parameter_types). Because we want a pointer to function, the * must be parenthesized with the identifier to ensure it binds before the function-call operator (). Then we place the function's parameter list inside the parentheses and put the intended return type to the left of the entire construct. Finally, we specify that the single parameter is a pointer to int (int*), and the function returns float*. Step-by-Step Solution: 1) Start with the function's return type: float*. 2) Make a pointer to a function identifier: (*ptr). 3) Add the parameter list receiving an int pointer: (int*). 4) Combine: float *(*ptr)(int*). 5) Read aloud: ptr is a pointer to a function taking int* and returning float*. Verification / Alternative check: Introduce typedefs to simplify reading: typedef float* f_ret_t; typedef f_ret_t func_t(int*); then func_t *ptr; matches float *(*ptr)(int*). Compilers accept both forms equivalently, and typeof or IDE hover info typically confirms the signature. Why Other Options Are Wrong: float *(ptr)*int; — Invalid syntax and not a function pointer declaration. float *(*ptr)(int) — Parameter is int, not int*, so the parameter type is wrong. float (*ptr)(int) — Returns float, not float*; return type is wrong. Common Pitfalls: Forgetting parentheses around *ptr, which changes the meaning to “function returning pointer” instead of “pointer to function”. Confusing int with int* in the parameter list, which subtly changes the signature. Misreading operator precedence between * and (). Final Answer: float *(*ptr)(int*)

Question 6

C declarations: interpret the following declaration char **argv;

Accepted Answer

Introduction / Context: Understanding multi-level pointers is essential in C, especially for command-line arguments and arrays of strings. The identifier argv is widely used in main's formal parameter list as char *argv, representing an array of C strings where each element is a char and the array itself is addressed via a pointer to pointer to char. Given Data / Assumptions: Declaration under analysis: char **argv; We are interpreting only the type, not storage duration or qualifiers. A typical use case is main(int argc, char **argv). Concept / Approach: char* means “pointer to char”. Adding another * yields char** which means “pointer to pointer to char”. This is commonly used for an array-of-pointers representation of strings, where argv points to the first element of an array of char* values, each of which points to the first character of a NUL-terminated string. Step-by-Step Solution: 1) Recognize ** as two levels of indirection. 2) The outer pointer refers to an element of type char*. 3) Each char* then points to a sequence of char ending with '\0'. 4) Therefore argv is “pointer to a char pointer”. Verification / Alternative check: Indexing argv like argv[i] produces type char*, and dereferencing once *argv[i] yields char, consistent with a list of strings. This aligns with the standard practice of treating argv as an array of pointers to C strings. Why Other Options Are Wrong: Pointer to pointer — Too vague; it does not specify the base type char. Function pointer — No function declarator () is present. Member of function pointer — Nonsensical in C terminology. Common Pitfalls: Assuming char** is interchangeable with char*[]. They are related through array-to-pointer decay but not identical types in all contexts. Forgetting to allocate and terminate the array of pointers when constructing argv-like structures. Final Answer: argv is a pointer to a char pointer.

Question 7

C declarations: write a declaration for "A pointer to a function which receives nothing and returns nothing"

Accepted Answer

Introduction / Context: This item checks whether you can construct a function pointer type for a procedure that takes no arguments and returns no value. In modern C, an explicit (void) parameter list indicates no parameters; older code sometimes uses empty parentheses, which historically meant an unspecified parameter list. Both styles appear in real code and documentation. Given Data / Assumptions: Pointer to a function is required. The function returns nothing (void). The function takes no parameters. No qualifiers or calling conventions are specified. Concept / Approach: The scheme for function pointers is return_type (*identifier)(parameters). We therefore place the pointer declarator around the identifier with parentheses, and supply the parameter list. Using an empty list () is commonly seen; the most explicit modern form is (void) to declare no parameters. Thus, void (*ptr)() is acceptable, and void (*ptr)(void) is even clearer where supported by your coding standard. Step-by-Step Solution: 1) Choose return type: void. 2) Make a pointer to a function: (*ptr). 3) Provide parameter list: () or (void). 4) Final form: void (*ptr)(). Verification / Alternative check: With typedefs: typedef void proc_t(void); then proc_t *ptr; has the same meaning as void (*ptr)(void). Practical tests, like assigning ptr = &some_function; and invoking (*ptr)(); confirm correct behavior. Why Other Options Are Wrong: void *(ptr)*int; — Invalid grammar; mixes pointer declarators and parameters incorrectly. void *(*ptr)() — Declares a function pointer returning void*, not void. void *(*ptr)(*) — Not valid C syntax; parameter list cannot be a bare *. Common Pitfalls: Omitting parentheses around *ptr, which changes the declaration's meaning. Confusing returning void with returning void*; these are completely different types. Final Answer: void (*ptr)()

Question 8

C declarations: interpret the following declaration char *scr;

Accepted Answer

Introduction / Context: This item tests basic pointer declarations in C. The expression char *name; is one of the most common idioms and denotes a pointer that can reference a character or the first element of a character array representing a C string. Given Data / Assumptions: Declaration under analysis: char *scr; No qualifiers (const, volatile) or storage specifiers are present. We are only classifying the type, not its initialization or lifetime. Concept / Approach: In C, the * binds to the identifier as part of the declarator, so char *scr; defines scr as “pointer to char”. This pointer can hold the address of a single char object or the first element of a char buffer that is terminated with '\0' to represent a string. The declaration does not allocate storage for characters; it only allocates space for the pointer itself. Step-by-Step Solution: 1) Identify base type: char. 2) Apply pointer declarator * to the identifier: *scr. 3) Conclude scr has type char* (pointer to char). 4) Usage typically involves assignment from &ch or from a string literal to a const-qualified pointer when appropriate. Verification / Alternative check: sizeof(scr) equals the size of a pointer on the platform, not the size of a character buffer. Dereferencing *scr yields type char, which confirms the one-level indirection. Why Other Options Are Wrong: Pointer to pointer — Would require char **scr. Function pointer — No function declarator () exists. Member of function pointer — Not meaningful terminology in C type system. Common Pitfalls: Assuming char *scr allocates storage for a full string; it does not allocate the characters themselves. Forgetting const when pointing to string literals to avoid modifying read-only storage. Final Answer: scr is a pointer to char.

Question 9

C declarations: interpret the following declaration void *cmp();

Accepted Answer

Introduction / Context: Distinguishing between “function returning pointer” and “pointer to function” is central to reading C declarations. Here, void *cmp(); uses the function declarator directly on the identifier, with a pointer type as the function's return type. This pattern is common for factory functions that return untyped memory or opaque handles. Given Data / Assumptions: Declaration: void *cmp(); Return type: void* (pointer to void). Parameter list is unspecified in the old-style form; modern code would prefer void *cmp(void). Concept / Approach: Because () applies to the identifier cmp (no parentheses around *cmp), cmp is a function, not a pointer variable. The leading void* indicates that the function returns a pointer to void. Therefore the accurate English reading is “cmp is a function that returns a void pointer”. Step-by-Step Solution: 1) Identify postfix operator: () binds to cmp, so cmp is a function. 2) Inspect the type on the left: void*. 3) Conclude the function's return type is pointer to void. 4) Optionally specify parameters as (void) in modern declarations to mean no parameters. Verification / Alternative check: Compare against a pointer-to-function form: void (*cmp)(); would be a pointer to a function returning void, which is different. Typedefs can help: typedef void* anyptr; anyptr cmp(void); reads clearly and confirms the meaning. Why Other Options Are Wrong: Pointer to a void type — Incorrect; that would be void *p; and not a function declaration. Void type pointer variable — Misstates the form; cmp is declared as a function, not a variable. Returns nothing — That would be return type void, not void*. Common Pitfalls: Confusing void (no value returned) with void* (pointer return). Assuming empty parameter lists always mean no parameters; in modern C use (void) to be explicit. Final Answer: cmp is a function that return a void pointer.

Question 10

C declarations: write a declaration for "A pointer to an array of three chars"

Accepted Answer

Introduction / Context: This problem evaluates whether you can distinguish between “array of pointers” and “pointer to array” in C declarations. Arrays and pointers interact through decay in expressions, but their types are not interchangeable in declarations, and parentheses are essential to convey the correct binding. Given Data / Assumptions: We need a pointer to an array. The array has exactly 3 elements. Each element is of type char. Concept / Approach: The array type is “array of 3 char”, written char[3]. A pointer to that array type is written by putting parentheses around the identifier with the pointer declarator, yielding char (*ptr)[3]. The parentheses ensure that *ptr is evaluated before applying [3], so ptr is a pointer to a single array object of length 3, rather than an array of pointers or anything involving functions. Step-by-Step Solution: 1) Start from the target object: an array of 3 char ⇒ char[3]. 2) Take a pointer to that array type ⇒ (*ptr) and then apply [3] to the type, not the variable. 3) Final form: char (*ptr)[3]. 4) Reading: ptr is a pointer to an array of three char. Verification / Alternative check: sizeof(*ptr) equals 3 * sizeof(char). Indexing (*ptr)[i] is valid for i in {0,1,2}. By contrast, char *ptr[3] declares an array of 3 pointers to char, which is a different type and storage layout entirely. Why Other Options Are Wrong: char *ptr[3]() — Introduces function declarators and describes an array of functions or function pointers, which is not required. char (*ptr)*[3] — Invalid placement of declarators; not legal syntax. char (*ptr[3])() — Declares an array of 3 pointers to functions, not a pointer to an array. Common Pitfalls: Omitting parentheses around *ptr and accidentally declaring an array of pointers. Assuming pointer-to-array and array-of-pointers are interchangeable; they are not, and pointer arithmetic differs. Final Answer: char (*ptr)[3];

Question 11

C declarations: interpret the following declaration void (*cmp)();

Accepted Answer

Introduction / Context: This item checks your ability to recognize a function pointer type in C. The parentheses around *cmp are the telltale sign that cmp is not a function itself but a pointer to a function. Such pointers are used for callbacks, signal handlers, and dispatch tables. Given Data / Assumptions: Declaration: void (*cmp)(); Return type of the function: void. Parameter list: unspecified in old-style C; modern code would prefer void (*cmp)(void). Concept / Approach: Reading with precedence: () applied to the declarator would make a function, but the parentheses force *cmp to bind before (), turning the whole into “pointer to function”. The type to the left, void, is the function's return type. There is no star on the return type, so it does not return a pointer; it returns nothing (void). Step-by-Step Solution: 1) Identify (*cmp): cmp is a pointer. 2) The trailing () indicates that the pointed-to target is a function. 3) The function's return type is void. 4) Therefore cmp is a pointer to a function returning void. Verification / Alternative check: Using a typedef: typedef void handler_t(void); handler_t *cmp; is equivalent and often clearer. Assign cmp = &some_handler; and invoke through (*cmp)(); to validate behavior in code. Why Other Options Are Wrong: Pointer to a void function type — Slightly awkward but closest in spirit; however, the best precise phrasing is “pointer to a function that returns void”. Void type pointer function — Not meaningful; functions are not “pointer functions”. Function that returns a void pointer — Would be void* f(); not this declaration. Common Pitfalls: Forgetting parentheses around *cmp and accidentally declaring a function returning a pointer instead of a pointer to function. Assuming empty parameter lists always mean no parameters; prefer (void) for clarity in modern C. Final Answer: cmp is a pointer to a function which returns void .

Question 12

In C/C++, how should we interpret the declaration: int ptr[30]; Explain precisely what ptr represents in terms of arrays and pointers.

Accepted Answer

Introduction: Parsing mixed pointer–array declarations in C/C++ requires understanding declarator precedence. This question tests whether you can correctly interpret what the identifier represents when both * and [] appear in the declaration. Given Data / Assumptions: Declaration under analysis: int ptr[30]; Language rules: standard C/C++ declarator binding (array brackets bind tighter than the asterisk). No typedefs or parentheses altering precedence. Concept / Approach: In declarations, [] has higher binding precedence than . Therefore ptr[30] is considered first (an array of 30 elements). Each element has the remaining type * to int, i.e., pointer to int. So ptr is an array with 30 elements, and each element is an int. Step-by-Step Solution: 1) Start from the identifier: ptr.2) Apply closest binding operator: [] → ptr[30] means “ptr is an array of 30”.3) Apply the remaining * to the element type: each element is a pointer to int (int).4) Final interpretation: ptr is an array (size 30) of pointers to int. Verification / Alternative check: Typical usage like ptr[i] = &someInt; compiles because ptr[i] has type int and can store the address of an int. Declaring a pointer to an array would require parentheses: int (*p)[30]; Why Other Options Are Wrong: Pointer to an array of 30 integer pointers: that would be int **(*p)[30]; with different grouping.Array of 30 integer pointers: this is semantically the same as the correct option, but wording should clearly state “pointers to integers.”Array 30 pointers: grammatically incomplete and type-unspecified. Common Pitfalls: Forgetting that [] binds tighter than * leads many to read it as “pointer to array” rather than “array of pointers.” Always add parentheses if you intend pointer-to-array semantics. Final Answer: ptr is an array of 30 pointers to integers.

Question 13

Turbo C memory models — sizes of near, far, and huge pointers (pointer-to-pointer declarations).  #include<stdio.h>  int main() {  char near near ptr1; / near pointer to near char => near pointer size */  char near far ptr2; / far pointer to near ch…

Accepted Answer

Introduction / Context: In 16-bit Turbo C, pointer size depends on the memory model and the pointer qualifier: near (typically 16 bits), far (32 bits segment:offset), and huge (also 32 bits but normalized). This question asks for the sizes of pointers to pointer objects with different qualifiers. Given Data / Assumptions: ptr1 is a near pointer variable. ptr2 is a far pointer variable. ptr3 is a huge pointer variable. Concept / Approach: The size reported by sizeof(ptrX) is the size of the pointer variable itself, determined by its qualifier (near/far/huge). Near pointers are 2 bytes; far and huge pointers are 4 bytes in Turbo C. The pointee type (here, a near char) does not change the size of the pointer variable. Step-by-Step Solution: 1) ptr1 is near => sizeof(ptr1) = 2.2) ptr2 is far => sizeof(ptr2) = 4.3) ptr3 is huge => sizeof(ptr3) = 4. Verification / Alternative check: Compiling with Turbo C in small/medium model yields these sizes. Changing the variable qualifiers (e.g., making the pointee far) would not affect sizeof(ptrX), which depends on the pointer variable's own qualifier. Why Other Options Are Wrong: 4,4,8 or 2,4,8: Huge pointers are 4 bytes, not 8, on Turbo C. 4,4,4: Implies near is 4 bytes, which is incorrect for 16-bit near. Common Pitfalls: Confusing the qualifier placement in multi-level pointer declarations; remember sizeof applies to the variable's pointer type, not the target type's qualifier. Final Answer: 2, 4, 4

Question 14

In Turbo C (16-bit DOS memory model), what does this program print for the sizes of the declared pointer variables?  #include<stdio.h>  int main() {  char huge *near *ptr1; // ptr1: near pointer to (huge char *)  char huge *far *ptr2; // ptr2: far p…

Accepted Answer

Introduction / Context: This question tests how Turbo C (16-bit DOS memory model) represents pointer sizes when using near, far, and huge qualifiers. Understanding declaration binding and how sizeof applies to the pointer variable (not the pointee) is essential for legacy codebases and interviews. Given Data / Assumptions: Compiler: Turbo C in 16-bit DOS. Pointer sizes: near = 2 bytes, far = 4 bytes, huge = 4 bytes. Declarations: ptr1 is a near pointer; ptr2 is a far pointer; ptr3 is a huge pointer. Concept / Approach: In these declarations, the qualifier nearest to the identifier (ptr1/ptr2/ptr3) determines the size of that pointer variable. The qualifiers attached to inner pointer levels affect the types they point to, not the storage size of the outer pointer variable itself. Step-by-Step Solution: 1) char huge *near *ptr1; ⇒ ptr1 is a near pointer ⇒ sizeof(ptr1) = 2.2) char huge *far ptr2; ⇒ ptr2 is a far pointer ⇒ sizeof(ptr2) = 4.3) char huge huge ptr3; ⇒ ptr3 is a huge pointer ⇒ sizeof(ptr3) = 4.4) Therefore the output is 2, 4, 4. Verification / Alternative check: Compile a minimal program and compare sizeof of a variable declared as near, far, and huge in Turbo C; results match the stated sizes. Why Other Options Are Wrong: Option A: Assumes 8-byte huge pointer; in Turbo C, huge is 4 bytes. Option C/D: Misread the binding between qualifiers and the identifier. Common Pitfalls: Confusing the size of the pointer variable with the size of the pointed-to type; the latter does not affect sizeof(pointer). Final Answer: 2, 4, 4

Question 15

Under Turbo C (16-bit DOS), evaluate the sizes printed by this program with mixed near/far/huge on multi-level pointers:  #include<stdio.h>  int main() {  char huge *near *far *ptr1; // ptr1: far pointer to (near pointer to huge char)  char near *fa…

Accepted Answer

Introduction / Context: This problem checks how pointer qualifiers near/far/huge bind to the identifier and how sizeof reports the size of each variable in Turbo C (16-bit DOS). Given Data / Assumptions: Pointer sizes: near = 2 bytes, far = 4 bytes, huge = 4 bytes. sizeof reports the size of the pointer variable's representation. All code compiled in 16-bit small/compact memory models where these keywords are meaningful. Concept / Approach: Read declarations right-to-left. The qualifier directly adjacent to the identifier (ptr1/ptr2/ptr3) governs the representation size of that pointer variable. Step-by-Step Solution: 1) ptr1 is declared as far * ⇒ sizeof(ptr1) = 4.2) ptr2 is declared as huge * ⇒ sizeof(ptr2) = 4.3) ptr3 is declared as near * ⇒ sizeof(ptr3) = 2.4) Output sequence: 4, 4, 2. Verification / Alternative check: Create single-variable tests with the same qualifiers and inspect sizeof to confirm. Why Other Options Are Wrong: Option A/D: Assume 8-byte pointers or misassign sizes. Option B: Incorrectly treats ptr1 or ptr2 as near pointers. Common Pitfalls: Attaching the qualifier to the wrong level of indirection, or believing inner pointer qualifiers influence the outer pointer's sizeof. Final Answer: 4, 4, 2

Question 16

In Turbo C (DOS), determine the sizes printed by this program mixing dereferences in sizeof:  #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: sizeof can be applied either to a pointer variable or, after dereferencing, to another pointer type. This question mixes multi-level pointers with near/far/huge and asks you to resolve sizes under Turbo C (16-bit DOS). Given Data / Assumptions: near = 2 bytes; far = 4 bytes; huge = 4 bytes. ptr1 is a far pointer; ptr2 is a huge pointer to a far pointer to a near char pointer; ptr3 is a near pointer. Concept / Approach: Unroll types stepwise. Each * removes one indirection level and exposes the next pointer's qualifier, which determines sizeof at that level. Step-by-Step Solution: 1) sizeof(ptr1): ptr1 is far * ⇒ 4.2) sizeof(**ptr2): *ptr2 is a far *; **ptr2 is a near * ⇒ 2.3) sizeof(ptr3): ptr3 is near * ⇒ 2.4) Hence: 4, 2, 2. Verification / Alternative check: Print sizeof of each intermediate type in a separate test to see 4 (far *) and 2 (near *). Why Other Options Are Wrong: Option A: Treats all three as 4-byte pointers. Option C/D: Introduce impossible 8-byte sizes or wrong bindings. Common Pitfalls: Assuming dereferencing always yields a char rather than a pointer type at the next level; here **ptr2 still yields a pointer (near *). Final Answer: 4, 2, 2

Question 17

Turbo C (DOS) pointer sizes: predict the output for these declarations and sizeof calls:  #include<stdio.h>  int main() {  char far *near *ptr1; // near pointer  char far *far *ptr2; // far pointer  char far *huge *ptr3; // huge pointer  printf("%d,…

Accepted Answer

Introduction / Context: The task is to bind qualifiers correctly and recall that in Turbo C, near pointers are 2 bytes while far/huge pointers are 4 bytes. sizeof returns the storage size of the pointer variable itself. Given Data / Assumptions: near = 2; far = 4; huge = 4 bytes. Qualifiers next to the identifier set that pointer's representation. Concept / Approach: Read from the identifier outwards. The outermost qualifier adjacent to ptr1/ptr2/ptr3 governs their sizes. Step-by-Step Solution: 1) ptr1 is a near pointer ⇒ sizeof = 2.2) ptr2 is a far pointer ⇒ sizeof = 4.3) ptr3 is a huge pointer ⇒ sizeof = 4.4) Output: 2, 4, 4. Verification / Alternative check: Isolate the declarations and print sizeof individually; results will match. Why Other Options Are Wrong: Option A/D: Introduce an 8-byte size which Turbo C does not use for these pointers. Option B: Treats near as 4 bytes, which is incorrect. Common Pitfalls: Assuming inner levels affect the outermost pointer size for sizeof; they do not. Final Answer: 2, 4, 4

Question 18

Turbo C (DOS): evaluate sizeof results that mix pointer levels and dereferences:  #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), sizeof(*ptr…

Accepted Answer

Introduction / Context: This problem combines multi-level pointers with near/far/huge qualifiers and requires resolving the type at each dereference before applying sizeof in Turbo C (16-bit DOS). Given Data / Assumptions: near = 2 bytes; far = 4 bytes; huge = 4 bytes. ptr1 is far; ptr2 is far; *ptr3 is far. Concept / Approach: Unwrap one level at a time and record the qualifier at that level. sizeof reports the size of the pointer representation at the evaluated type. Step-by-Step Solution: 1) sizeof(ptr1): ptr1 is far * ⇒ 4.2) sizeof(*ptr2): ptr2 is huge * to (far *) ⇒ *ptr2 is far * ⇒ 4.3) sizeof(**ptr3): ptr3 is near * to (huge * to (far *)) ⇒ **ptr3 is far * ⇒ 4.4) Therefore the output is 4, 4, 4. Verification / Alternative check: Print intermediate sizeof values for *ptr2 and **ptr3 to confirm both are far pointers. Why Other Options Are Wrong: Options B/C/D: Misidentify which level is being measured by sizeof or assume an incorrect 2-byte result. Common Pitfalls: Jumping directly to the base char type instead of recognizing that dereferencing here still yields a pointer type. Final Answer: 4, 4, 4

Question 19

C typedefs and shadowing in Turbo C: what does this program print?  #include<stdio.h> typedef void v; typedef int i;  int main() {  v fun(i, i);  fun(2, 3);  return 0; }  v fun(i a, i b) {  i s = 2; // s is int  float i; // here, i is a variable of …

Accepted Answer

Introduction / Context: This question checks understanding of typedef names versus identifiers and how a local variable can shadow a typedef name, affecting sizeof and evaluation of expressions in Turbo C. Given Data / Assumptions: In Turbo C: sizeof(int) = 2, sizeof(float) = 4 (typical 16-bit). typedef i = int; typedef v = void. Local declaration float i; introduces a variable named i of type float, shadowing the typedef name i. Concept / Approach: sizeof(i) refers to the variable i (type float), not the typedef. The arithmetic abs uses ints: a = 2, b = 3, s = 2, so the product is 12. Step-by-Step Solution: 1) Shadowing: within fun, float i; means i is a variable, so sizeof(i) = sizeof(float) = 4.2) Compute abs = 232 = 12.3) Output format prints "4, 12". Verification / Alternative check: Rename the variable (e.g., float f;) and observe sizeof now prints 2 if you use sizeof(i) where i is the typedef int. Why Other Options Are Wrong: Options A/B/C assume incorrect sizes or miscompute the product. Common Pitfalls: Confusing typedef names with variables; sizeof applied to an identifier uses the identifier's current binding in scope. Final Answer: 4, 12

Question 20

Unsigned wraparound in Turbo C (DOS): what does this program print?  #include<stdio.h> typedef unsigned long int uli; typedef uli u;  int main() {  uli a;  u b = (u)-1;  a = (uli)-1;  printf("%lu, %lu", a, b);  return 0; }

Accepted Answer

Introduction / Context: This checks knowledge of unsigned wraparound and typical widths under Turbo C. Casting -1 to an unsigned type yields the maximum representable value for that type. Given Data / Assumptions: In 16-bit Turbo C, unsigned long is 32-bit. printf with %lu expects unsigned long. Both a and b are unsigned long values assigned -1 after casting. Concept / Approach: Two's complement and modulo arithmetic: (unsigned long)-1 maps to 2^32 - 1 = 4294967295. Step-by-Step Solution: 1) a = (unsigned long)-1 ⇒ 4294967295.2) b = (unsigned long)-1 via typedef u ⇒ 4294967295.3) Printing both yields "4294967295, 4294967295". Verification / Alternative check: Print sizeof(unsigned long) to confirm 4, then print the values. Why Other Options Are Wrong: Options A/B are arbitrary numbers; Option D is incorrect because defined unsigned wraparound is not garbage. Common Pitfalls: Using a wrong format specifier (e.g., %u) or assuming 64-bit widths on modern systems; this is specific to Turbo C. Final Answer: 4294967295, 4294967295

Complicated Declarations Questions