Question 1

Pointers and qualifiers in C: What happens when calling fun(&ptr) if fun expects int ** but ptr has type const int * in the given program?

Accepted Answer

Introduction / Context: Type qualifiers such as const are part of a variable’s type in C. When you add layers of indirection (pointers to pointers), discarding qualifiers through an implicit conversion becomes dangerous and therefore illegal. This question explores why passing the address of a const int * to a function parameter of type int ** is ill-formed, even though both involve pointers to pointers conceptually. Given Data / Assumptions: ptr is declared as const int *ptr = &i; fun is declared as int fun(int **ptr) and is called as fun(&ptr); The function body later tries to redirect the pointer to a non-const int (via a temporary). Concept / Approach: A parameter of type int ** allows the callee to store an int * into the caller’s pointer. But the caller’s pointer is a const int *, meaning it may not point to a modifiable int. Allowing an int ** parameter would permit the callee to assign a non-const int * into that location, breaking const-correctness. Therefore, conversion from const int ** to int ** is prohibited to preserve type safety. Step-by-Step Solution: Caller provides &ptr → type is const int **.Callee expects int ** → types are not compatible.Compiler emits a diagnostic: cannot convert from const int ** to int **.Program fails to compile; no runtime output is produced. Verification / Alternative check: Consider what would happen if allowed: callee writes an int * pointing to modifiable memory into the location of a const int *; the caller could then modify an object that was intended to be read-only. The restriction prevents this. Why Other Options Are Wrong: Printing addresses or values implies successful compilation; it does not. Garbage value: irrelevant because compilation already fails. ”Address of i Address of j”: presumes behavior that cannot occur under strict type checking. Common Pitfalls: Confusing top-level const (the pointer itself) with low-level const (the pointed-to object). The latter is what blocks the conversion here. Using casts to silence the error; this risks undefined behavior by violating const-correctness. Final Answer: Error: cannot convert parameter 1 from 'const int **' to 'int **'

Question 2

Const-correctness and arrays: Given a const int array in Turbo C and a function fun(int *), what is the outcome of calling fun(&arr[3]) after printing arr[3]?

Accepted Answer

Introduction / Context: Const-correctness ensures that objects declared read-only are not modified inadvertently. When a function takes an int *, passing it the address of a const int violates that promise. Even though some legacy compilers accept such code with only a warning, the intent of the language is to forbid discarding const implicitly. This question examines the compile-time consequence of attempting to modify a const array element through a non-const pointer parameter. Given Data / Assumptions: const int arr[5] = {1,2,3,4,5}; int fun(int *f) { *f = 10; return 0; } Call site: fun(&arr[3]); after printing arr[3]. Concept / Approach: The type of &arr[3] is const int *. Converting to int * would allow writing through the pointer to a const object, which is disallowed. Modern compilers issue an error; older ones might warn but still compile, leading to undefined behavior at runtime if a write occurs. Therefore, the correct, standard-conforming outcome is a type error at the call. Step-by-Step Solution: Identify parameter type mismatch: fun expects int * but receives const int *.Implicit cast would remove const → forbidden.Compiler issues a diagnostic; the program should not compile successfully. Verification / Alternative check: If you change fun to accept const int * and remove the write, the call compiles. If you remove const from arr, the original fun compiles and sets arr[3] to 10. Why Other Options Are Wrong: ”Before…4 After…10”: implies the illegal write succeeded. ”Invalid parameter”: vague, not the standard type mismatch description. ”Before…4 After…4”: would require that the write be ignored; the core issue is a compile-time type error. Common Pitfalls: Assuming that a warning is harmless; writing through a pointer to const invokes undefined behavior. Confusing array decays and pointer types; the const-qualification applies to the pointed-to object. Final Answer: Error: cannot convert parameter 1 from const int * to int *

Question 3

Initialization of const from a function: What will be printed when const int x = get(); with get() returning 20 is executed and x is printed?

Accepted Answer

Introduction / Context: Constants in C can be initialized with constant expressions or the results of function calls that are evaluated at runtime before first use. The const qualifier means the object cannot be modified after initialization, not that its initializer must be a compile-time literal. This problem clarifies that distinction by initializing a const int using a function that returns a known value and then printing it. Given Data / Assumptions: int get() { return 20; } const int x = get(); printf("%d", x); is used to display the value. Concept / Approach: In C, function calls are valid initializers for automatic storage-duration variables, even if they are qualified const. The qualifier const prevents subsequent modification through that identifier, but does not restrict the initializer to literals. Since get() reliably returns 20, x is initialized to 20 and printing x yields 20. Step-by-Step Solution: Call get() during initialization → result 20.Bind result to x as a const int → x holds 20 and is read-only thereafter.printf("%d", x) → prints 20. Verification / Alternative check: If get() returned a different integer, that value would be printed; the presence of const does not change the initialization semantics. Why Other Options Are Wrong: Garbage value/0/implementation-defined: the value is clearly determined by get(). Error: there is nothing illegal about initializing a const with a function return value. Common Pitfalls: Confusing const with compile-time constant; in C (unlike some contexts in C++), const is not necessarily a constant expression. Assuming that const implies static storage; it does not. Final Answer: 20

Question 4

Binding a const to a non-const value: After int y = 128; const int x = y; what is printed by printf("%d ", x)?

Accepted Answer

Introduction / Context: The const qualifier stops further mutation through the declared name, but it does not alter the stored value at initialization. Assigning or initializing a const from an ordinary variable is routine and results in an independent read-only object that holds the copied value at that moment. This question reinforces that constness affects mutability, not representable values or printing behavior. Given Data / Assumptions: int y = 128; const int x = y; We print x using %d. Concept / Approach: Initialization copies the value of y into x; x is then read-only. There is no type mismatch: both are of type int; const is a qualifier on x's object, not a different base type. Therefore, printing x yields 128. Step-by-Step Solution: Compute initial state: y holds 128.Initialize const int x with y → x = 128.Print x → output 128. Verification / Alternative check: Changing y later would not affect x; x remains 128 since it is a distinct object. Why Other Options Are Wrong: Garbage value/0: contradicts straightforward initialization. Error: no rule forbids initializing a const int from a non-const int. Unspecified behavior: there is no unspecified behavior in this sequence. Common Pitfalls: Confusing const int x = y; with binding a reference (a C++ concept). In C, it is simply value initialization. Thinking that const implies compile-time constness; here it is a runtime copy but a read-only one thereafter. Final Answer: 128

Question 5

Applying ++ to a const object: For const int i = 0; what happens when evaluating printf("%d ", i++);?

Accepted Answer

Introduction / Context: Unary increment (postfix or prefix) requires a modifiable lvalue because it actually writes back to the operand after computing its value. When an object is declared const, the language forbids modifying it through that identifier. This question checks your understanding by applying the post-increment operator to a const-qualified integer and observing the result at compile time. Given Data / Assumptions: const int i = 0; printf("%d
", i++); Standard C operator semantics apply. Concept / Approach: Post-increment on an expression E evaluates E, then stores E+1 back into the same object. Because i is const, storing the new value is not permitted; i is not a modifiable lvalue. Therefore, the expression is ill-formed, and the compiler must diagnose it. Step-by-Step Solution: Identify operator → i++ requires write-back to i.Check object mutability → i is const → write disallowed.Compilation error occurs; typical messages include 'lvalue required' or 'increment of read-only variable'. Verification / Alternative check: Replacing i++ with (i + 1) compiles, because that expression does not modify i; it only computes a temporary value. Why Other Options Are Wrong: 10/11: imply successful execution and arithmetic; code will not compile. No output: implies runtime suppression; the failure happens at compile time. Undefined behavior: the standard forbids the operation; a diagnostic is required. Common Pitfalls: Confusing const with compile-time constant: the issue here is mutability, not evaluation timing. Assuming prefix ++i would differ; both require a modifiable lvalue and are equally invalid on const. Final Answer: Error: ++needs a value

Question 6

Printing through a pointer-to-const: In Turbo C, given const int *ptr pointing to i, then reassigned to j, what is the likely output of printing the pointer values (as hex) and the pointed integers?

Accepted Answer

Introduction / Context: A pointer-to-const (const int *) allows reading the pointed value but not modifying it. Reassigning the pointer itself to point to a different object is legal because the pointer is not const-qualified here. The program prints the address held in the pointer (using a hex-like format) and then the value obtained by dereferencing it, first for i and then after reassigning to j. While exact addresses vary, the pattern of printing the current address and associated value is predictable. Given Data / Assumptions: Two ints exist: i = 10 and j = 20. const int *ptr = &i; then later ptr = &j; The code prints the pointer value with %5X (non-portable for pointers) and then the dereferenced integer with %d. Concept / Approach: Pointer-to-const restricts writes through the pointer, not reassignment of the pointer variable. Printing a pointer with %X is technically undefined in standard C; however, many DOS/Turbo C environments treated pointers and integers similarly, and the exercise expects a schematic address-value pairing. Thus, the intended correct output shows two address prints (for &i and &j) and two integer prints (10 then 20). Step-by-Step Solution: Initialize ptr to &i → dereference prints 10 after showing some address.Reassign ptr to &j → dereference prints 20 after showing the new address.Among the options, only one displays values 10 and 20 in that order, paired with plausible hex addresses. Verification / Alternative check: Running analogous code on Turbo C typically yields two distinct near-pointer values and the expected integers. Modern compilers require using %p to print pointers portably. Why Other Options Are Wrong: Options with 12/24 or 20/30 imply different numeric values than the program stores. Garbage value: while %X for pointers is non-portable, the exercise assumes meaningful display. Compilation error due to const: reading through const int * is fine; only writing would error. Common Pitfalls: Believing const applies to the pointer itself; it applies to the pointed-to object in this declaration. Using %X or %d for pointers in portable C; %p is the correct specifier with a cast to void *. Final Answer: i= FFE4 ptr=10 j=FFE2 ptr=20

Question 7

Reading and printing a C string via a pointer-to-const: With const char *s = "" then s = str where str is "Hello", what does the loop while(*s) printf("%c", *s++); print?

Accepted Answer

Introduction / Context: In C, a pointer declared as const char * may point to a character array, and you are allowed to move the pointer and read characters through it; the const qualifier forbids writing through the pointer, not reassigning the pointer itself. This question checks understanding of pointer iteration over a NUL-terminated string using a simple while loop that stops at the terminating '\0'. Given Data / Assumptions: const char *s = ""; then char str[] = "Hello"; s = str; Loop: while (*s) printf("%c", *s++); Standard C string semantics: arrays are NUL-terminated. Concept / Approach: The condition *s is true for any non-zero character; it becomes false at the NUL terminator. The expression *s++ prints the current character and then advances the pointer to the next character (post-increment of the pointer). No writes occur through s, so const-correctness is respected. Step-by-Step Solution: Start: s points to 'H' → print 'H', advance to 'e'.Next: print 'e', advance to 'l'.Then: print 'l', advance to second 'l'.Then: print 'l', advance to 'o'.Finally: print 'o', advance to '\0' → loop ends. Verification / Alternative check: Replacing the loop with puts(str) would also print 'Hello' followed by a newline; our loop prints without adding a newline. Why Other Options Are Wrong: Error/Undefined behavior: no invalid operations occur; only reads and pointer increments. 'H' or 'Hel': would require an early exit; the loop continues until NUL. Common Pitfalls: Misreading *s++ as (*s)++ (which would attempt to modify the character); precedence rules mean it is *(s++), a pointer increment, not a character increment. Forgetting that the empty string "" initially is harmless since s is later reassigned to str before use. Final Answer: Hello

Question 8

Attempting to write into a const union member: Given const union employee e1; and strcpy(e1.name, "K");, what is the compilation result?

Accepted Answer

Introduction / Context: Declaring an object as const in C makes the entire object read-only. For aggregates such as structs and unions, each member becomes non-modifiable through that object. Attempting to write into a member via functions like strcpy therefore violates const-correctness and must be diagnosed by the compiler. This question highlights how const applies transitively to members of a union and how that affects typical string-copy operations. Given Data / Assumptions: union employee { char name[15]; int age; float salary; }; const union employee e1; declares a read-only union object. strcpy(e1.name, "K"); attempts to modify a member array. Concept / Approach: Because e1 is const, its member name is a non-modifiable lvalue. Passing it to strcpy (which expects a char * destination) is illegal: the expression has type const char * after array-to-pointer decay. Compilers typically emit diagnostics such as 'assignment of read-only location' or 'lvalue required' for the attempted write. Even if forced via casts, modifying a const object produces undefined behavior. Step-by-Step Solution: Check object qualification: e1 is const → all members non-modifiable.strcpy destination requires writable memory → e1.name is not writable.Compilation fails with an error indicating invalid attempt to write to a const object. Verification / Alternative check: If e1 were non-const, strcpy would compile; or, if you used a separate writable buffer, no error would occur. Why Other Options Are Wrong: RValue required: the issue is not rvalue vs lvalue, but non-modifiable lvalue. Type-conversion message about int pointers: unrelated to this code. No error/Runtime crash only: incorrect; this is a compile-time const violation. Common Pitfalls: Casting away const to appease strcpy; writing through such a cast is undefined behavior. Assuming const applies only to scalars; it applies to aggregates as well. Final Answer: Error: LValue required in strcpy

Question 9

Dereferencing a pointer-to-const bound to a const object: With const int x = 5; const int *ptrx = &x; what happens when executing *ptrx = 10; then printing x?

Accepted Answer

Introduction / Context: In C, a pointer declared as const int * is a pointer to a read-only integer. The qualifier applies to the pointed-to object as accessed through that pointer. Attempting to assign through such a pointer is forbidden and should trigger a compiler error, safeguarding program correctness by preventing unintended writes to protected data. Given Data / Assumptions: const int x = 5; const int *ptrx = &x; Statement: *ptrx = 10; followed by printing x. Concept / Approach: The expression *ptrx designates a non-modifiable lvalue because ptrx points to const-qualified int. Assigning a new value to a non-modifiable lvalue is illegal; compilers issue messages like 'assignment of read-only location'. Therefore, the program fails to compile at the assignment; no runtime output is produced. Step-by-Step Solution: Determine the effective type of *ptrx → const int.Check assignment legality → writing to const object → not allowed.Compilation error occurs; the printf is never reached. Verification / Alternative check: If ptrx were declared int * and pointed to a non-const int, *ptrx = 10 would be valid. If you tried to cast away const and still write, behavior would be undefined even if it appears to work on some platforms. Why Other Options Are Wrong: 5 or 10: imply successful execution, but the assignment will not compile. Garbage value: not applicable; the code does not run. Warning-only scenario: standards-compliant compilers treat this as an error when you attempt the assignment. Common Pitfalls: Misunderstanding that const applies to the pointer vs the pointee; here, the pointee is const. Believing that casting away const makes it safe to write; it does not if the original object was defined const. Final Answer: Error

Question 10

C programming: what will be the output of this program on a standards-compliant compiler? #include<stdio.h>  int main() { const c = -11; const int d = 34; printf("%d, %d ", c, d); return 0; }

Accepted Answer

Introduction / Context: This question checks your understanding of declarations, type qualifiers (const), and compilation rules in C. While many compilers offer extensions, a strictly conforming C compiler requires that every object declaration include a type. Printing behavior only matters if the code compiles, so the key concept is whether the declaration of c is valid C. Given Data / Assumptions: c is declared as const c = -11; (no explicit type). d is declared as const int d = 34; (valid). printf uses the %d format for both values. Assume a standard-conforming compiler (ISO C), not compiler-specific extensions. Concept / Approach: In ISO C, const is a type qualifier that must qualify a complete type such as int, double, etc. A declaration like const c = -11; omits the base type, making the declaration ill-formed and causing a compile-time error. Some historical or non-conforming modes might treat it as int, but that is not guaranteed by the C standard. Step-by-Step Solution: 1) Parse declaration: const appears without a type ⇒ invalid declaration. 2) The compiler reports a syntax or type error before linking or running. 3) Because compilation fails, no program output is produced. Verification / Alternative check: Try compiling with a standards-conforming mode (for example, enable ISO C warnings). The compiler will reject the declaration of c. Changing it to const int c = -11; makes the program valid and then the output would be -11, 34. Why Other Options Are Wrong: -11, 34: Would only be correct if c had a valid type, e.g., const int. 11, 34: The sign would not flip; there is no operation that negates -11. None of these: The precise correct choice is “Error”. Common Pitfalls: Assuming const implies int by default—this is not guaranteed by the standard. Testing on permissive compilers and generalizing the behavior as portable. Final Answer: Error

Question 11

C program diagnosis: modifying a const union and printing its members #include #include #include union employee { char name[15]; int age; float salary; }; const union employee e1; int main() { strcp…

Accepted Answer

Introduction / Context: This item tests const-correctness with aggregates. The union instance e1 is declared const, yet the code attempts to modify its members via strcpy and direct assignment. Given Data / Assumptions: union employee e1 is qualified with const. Operations attempt to write into e1.name and e1.age. strcpy requires a writable destination. Concept / Approach: In C, const at the object level forbids any modification through that object. Accessing a member of a const union yields a const-qualified lvalue for that member. Therefore, both strcpy(e1.name, ...) and e1.age = 85 violate const-correctness. Step-by-Step Solution: Declaration: const union employee e1; → all member writes are forbidden.strcpy(e1.name, "K"); → attempts to write into a const char array → constraint violation.e1.age = 85; → attempts to write into const int → also a violation.Even reading different members of a union is fine, but writing is disallowed due to const. Verification / Alternative check: Remove const (union employee e1;) or use a non-const temporary. Also add #include to avoid implicit declaration (modern compilers). Why Other Options Are Wrong: “RValue/LValue required” do not describe the fundamental issue. “No error” is false; compilers diagnose attempts to modify const objects. Common Pitfalls: Assuming const applies only to the union itself but not its members; forgetting to include string.h; misunderstanding that union type does not change const semantics. Final Answer: Error: cannot modify const object

Question 12

Const-correctness check in C: assigning a const char* to a non-const char* variable

#include<stdio.h>
const char *fun();

int main()
{
 char *ptr = fun();
 return 0;
}
const char *fun()
{
 return "Hello";
}

Accepted Answer

Introduction / Context: This question evaluates const-correct pointer assignments involving string literals. Function fun returns const char pointing to read-only storage, while main tries to store it in a modifiable char. Given Data / Assumptions: fun() returns const char . main defines char ptr and initializes it with fun(). String literals reside in read-only memory in most C implementations. Concept / Approach: Assigning const char to char discards qualifiers. This is not allowed in modern, strictly conforming C because it would allow writes through ptr to read-only memory, causing undefined behavior. Compilers issue an error or at least a diagnostic preventing it. Step-by-Step Solution: fun() → returns pointer of type const char *.ptr is declared as char * (non-const).Initialization attempts to drop const → constraint violation.Fix by declaring const char *ptr = fun(); Verification / Alternative check: Try compiling after changing ptr to const char *. The program compiles cleanly. Any attempt to write through ptr (e.g., ptr[0] = 'X') will then be correctly rejected at compile time. Why Other Options Are Wrong: “Lvalue required” is irrelevant; the issue is qualifier mismatch. “No error” is incorrect for standard-conforming compilers. “None of above” is unnecessary when (b) states the precise reason. Common Pitfalls: Forgetting that string literals are not mutable; believing const can be silently dropped; mixing old K&R compiler behavior with modern C rules. Final Answer: Error: cannot convert 'const char *' to 'char *'.

Question 13

Turbo C (non-C99) diagnostic: using a const int variable as an array bound vs a #define constant

#include<stdio.h>
#define MAX 128

int main()
{
 const int max = 128; /* not an ICE in old Turbo C /
 char array[max]; / variable length array …

Accepted Answer

Introduction / Context: This question contrasts classic Turbo C behavior with modern C99+. In Turbo C (pre-C99), array bounds must be compile-time integer constant expressions (ICEs). A const int variable is not an ICE for that compiler. Given Data / Assumptions: Compiler: Turbo C (16-bit, pre-C99). #define MAX 128 provides a true compile-time constant. const int max = 128 is not treated as an ICE by Turbo C. Concept / Approach: In old compilers without variable length arrays (VLAs), array sizes must be literal constants, enum constants, or macro constants. Using const int max as an array bound triggers an error similar to “constant expression required.” Step-by-Step Solution: Define const int max = 128; → not an ICE in Turbo C.Declare char array[max]; → Turbo C errors: constant expression required.Declare char string[MAX]; → OK because MAX is a macro constant.Hence the program fails to compile due to array[max]. Verification / Alternative check: On a modern C99+ compiler with VLAs, char array[max]; would compile. Specifying -std=c89 or using Turbo C reproduces the error. Why Other Options Are Wrong: “invalid array string” misidentifies the line. “No error” is false for Turbo C. “None of above” is unnecessary because (a) states the correct diagnostic. Common Pitfalls: Assuming const int is always a compile-time constant; confusing language standards and compiler capabilities; forgetting that VLAs appeared only in C99. Final Answer: Error: unknown max in declaration/Constant expression required

Question 14

C const-correctness: attempting to modify a string literal through a const char* return value

#include<stdio.h>
const char *fun();

int main()
{
 *fun() = 'A';
 return 0;
}
const char *fun()
{
 return "Hello";
}

Accepted Answer

Introduction / Context: This question checks whether you can write through a pointer to const data returned by a function. The code dereferences the returned pointer and assigns a character, attempting to mutate a string literal. Given Data / Assumptions: fun returns const char * to the literal "Hello". main executes fun() = 'A'; String literals are not modifiable. Concept / Approach: A string literal has static storage and is non-modifiable. Returning a const char correctly advertises immutability. Dereferencing that pointer as an lvalue target of assignment violates const and, if forced, would lead to undefined behavior. Step-by-Step Solution: fun() → const char * to "Hello".*fun() is a const-qualified char lvalue.Assigning 'A' attempts to modify read-only memory → compile-time error in strictly conforming compilers. Verification / Alternative check: Change fun to return char * but still return a literal: some compilers allow compilation but crash at runtime. Correct approach: copy into a writable array first. Why Other Options Are Wrong: “Rvalue/Lvalue required” do not precisely address const immutability. “No error” is wrong in standard-conforming code; writing to a literal is invalid. Common Pitfalls: Forgetting const on function returns; writing into string literals; assuming dereferencing a pointer always yields a modifiable lvalue. Final Answer: Error: fun() returns a pointer const character which cannot be modified

Question 15

Const qualifier on the pointed-to data: diagnose the error when writing through a pointer to const

#include<stdio.h>

int main()
{
 char mybuf[] = "India";
 char yourbuf[] = "CURIOUSTAB";
 char const ptr = mybuf; / pointer to const char */\…

Accepted Answer

Introduction / Context: This problem checks understanding of “pointer to const” versus “const pointer.” Here, ptr is declared as char const *ptr, which means the characters pointed to must not be modified through ptr. The pointer itself is not const and may be reassigned. Given Data / Assumptions: mybuf and yourbuf are writable arrays. ptr is a pointer to const char. The code tries *ptr = 'a' which attempts to modify via a const-qualified access. Concept / Approach: With char const *ptr, the pointed-to data is read-only through ptr. Writing via *ptr is a constraint violation. Reassigning ptr = yourbuf is fine because ptr itself is not const. The precise error is “assignment of read-only location.” None of the provided choices (a, b, c) correctly name this, so “None of above” is the accurate selection. Step-by-Step Solution: Declare ptr as pointer to const.Attempt *ptr = 'a'; → compile-time error: expression must be modifiable lvalue / read-only location.Line ptr = yourbuf; → valid reassignment. Verification / Alternative check: Change the declaration to char *ptr = mybuf; and the assignment will compile and run. Alternatively, change to char *const ptr = mybuf; to make the pointer itself const and observe that ptr = yourbuf; then fails. Why Other Options Are Wrong: (a) and (b) mention conversions not present. (c) claims no error, which is incorrect due to the attempted write through a const-qualified pointer. Common Pitfalls: Confusing char const * (data const) with char *const (pointer const); believing that writable arrays remove const restrictions imposed by a pointer type. Final Answer: None of above

Question 16

Const object initialization rule in C: diagnosing assignment after declaration

#include<stdio.h>

int main()
{
 const int x; /* uninitialized /
 x = 128; / attempted assignment after declaration */
 printf("%d
", x);
 return 0;
}

Accepted Answer

Introduction / Context: This question evaluates understanding of const object initialization in C. A const object must be initialized at the point of its definition; further assignments are not allowed. Given Data / Assumptions: x is declared as const int without an initializer. Later, x = 128 attempts to assign a new value. Standard C rules apply. Concept / Approach: Declaring const int x; creates a read-only object. Because it cannot be assigned to after declaration, you must initialize it immediately, e.g., const int x = 128;. Attempting to assign later violates const, producing a compile-time error. Step-by-Step Solution: Parse declaration: const int x; → needs initializer to set value.Line x = 128; → illegal: assignment to const object.Fix by writing const int x = 128; and removing the later assignment. Verification / Alternative check: Compile both versions: the incorrect one fails; the corrected one compiles and prints 128. Why Other Options Are Wrong: (a) “unknown data type” is false—const int is valid. (c) “stack overflow” is irrelevant. (d) claims no error, which is incorrect. Common Pitfalls: Believing const only prevents taking the address or only applies to pointer targets; assuming you can “set once later.” Final Answer: Error: const variable have been initialised when declared.

Question 17

Type qualification mismatch: binding a pointer to non-const int to the address of a const int

#include<stdio.h>

int main()
{
 const int k = 7;
 int const q = &k; / constant pointer to non-const int */
 printf("%d", *q);
 return 0;
}

Accepted Answer

Introduction / Context: This tests qualifier compatibility. The expression &k has type const int, but the code tries to initialize q as an int *const, i.e., a constant pointer to non-const int. That discards const on the pointed-to type. Given Data / Assumptions: k is const int. &k is of type const int *. q is declared as int *const (pointer itself const, target non-const). Concept / Approach: Type int *const means “a const pointer to int.” The target type is int (modifiable). Assigning the address of a const int to a pointer to non-const int would allow writes to a const object through q, which is forbidden. The correct type would be const int *const q = &k;. Step-by-Step Solution: Compute &k → const int *.Attempt to bind to int *const → discarding const on pointee.Compilation error: cannot convert from const int * to int *const.Fix: make q a pointer to const: const int *const q = &k; Verification / Alternative check: With the corrected declaration, dereferencing *q yields 7, but q cannot be used to modify k. Why Other Options Are Wrong: Rvalue/Lvalue diagnostics are not the issue. “No error” is incorrect because qualifiers are mismatched. Common Pitfalls: Confusing "const pointer" with "pointer to const"; overlooking that const applies to the pointee type here. Final Answer: Error: cannot convert from 'const int *' to 'int *const'

Question 18

Const pointer vs pointer to const: identify the actual error in reassignment

#include<stdio.h>

int main()
{
 char mybuf[] = "India";
 char yourbuf[] = "CURIOUSTAB";
 char const ptr = mybuf; / const pointer to char (pointer is fixed) */
 p…

Accepted Answer

Introduction / Context: This question distinguishes between “const pointer to T” (T *const) and “pointer to const T” (const T *). Here, the pointer itself is const, so it cannot be reseated to point elsewhere, although the data it points to is modifiable. Given Data / Assumptions: ptr is declared char *const ptr = mybuf; mybuf and yourbuf are writable arrays. *ptr = 'a' modifies the first character of mybuf—this is legal. ptr = yourbuf; attempts to reassign the const pointer—this is illegal. Concept / Approach: A const pointer cannot have its stored address changed after initialization. The error is not a “conversion” but an assignment to a const object. Typical diagnostics: “assignment of read-only variable ‘ptr’.” None of the listed answers (a–c) precisely describe this, so “None of above” is correct. Step-by-Step Solution: Declare const pointer: ptr fixed to mybuf.Write through ptr: allowed because the pointee type is non-const.Attempt to reassign ptr: forbidden → compile-time error. Verification / Alternative check: Change declaration to char *ptr = mybuf; and reassignment compiles. Or change to const char *ptr = mybuf; and note you cannot write *ptr = 'a', showing the orthogonal roles of the two "const" positions. Why Other Options Are Wrong: (a) and (b) mischaracterize the issue as conversion. (c) claims no error, but reassignment of a const pointer is invalid. (e) suggests a runtime failure; the failure is at compile time. Common Pitfalls: Mixing up T *const with const T *; thinking const always applies to the pointee rather than the pointer itself. Final Answer: None of above

Constants Questions