Question 1

In standard C, is there a built-in, portable way to print the symbolic names of enum constants at runtime, or must we create our own mapping?

Accepted Answer

Introduction / Context: Enums are integers at runtime. This question examines whether C provides a standard mechanism to obtain the symbolic names of enum constants as strings when printing or logging. Given Data / Assumptions: We have an enumeration type with named constants. We want to print names like RED, GREEN, BLUE at runtime. Concept / Approach: The C standard does not retain identifier names for runtime reflection. Enums decay to integral values; there is no standard function to map an enum value back to its identifier name. Programmers typically implement a manual mapping, such as a string array aligned with enum values or a switch statement that returns the corresponding string. Step-by-Step Solution: 1) Define enum: `enum Color { RED, GREEN, BLUE };` 2) Create mapping: `const char* names[] = { "RED", "GREEN", "BLUE" };` 3) Print by index: `printf("%s", names[value]);` (validate range). 4) Alternatively, write a switch that returns a string literal for each case. Verification / Alternative check: Trying to print with `%s` on an enum without a mapping fails; the compiler does not know names at runtime. Why Other Options Are Wrong: Option B/C/D/E: No such standard feature or flag exists; sizeof gives size, not names, and build mode does not add reflection. Common Pitfalls: Forgetting to keep mapping in sync; relying on non-portable compiler extensions; not handling unknown values safely. Final Answer: No—provide your own mapping such as an array of strings or a switch.

Question 2

Accessing union members in C: Do we always need the address-of (&) operator, or do we use the member access operator (.) to read/write fields?

Accepted Answer

Introduction / Context: C provides different operators for accessing data. This question focuses on how to access union members and clarifies the roles of the . (member access), -> (pointer dereference then member access), and & (address-of) operators. Given Data / Assumptions: A union variable exists, e.g., `union U u;` We want to read or write its fields. Concept / Approach: To access a member of a union object directly, use the `.` operator: `u.x = 5;`. If you have a pointer to a union, use `->`: `pu->x`. The `&` operator merely produces the address of the union object or a member; it does not read or write values. Step-by-Step Solution: 1) With an object: `u.member` reads/writes the member. 2) With a pointer: `p->member` is equivalent to `(*p).member`. 3) Use `&u` or `&u.member` only when a function requires an address parameter. 4) Conclude that `&` is not for accessing members’ values. Verification / Alternative check: Compile small examples to see that `u.member` works, while attempting to treat `&` as an access operator is a category error. Why Other Options Are Wrong: Option B: Misuses `&`. Option C: `->` requires a pointer; using it on a non-pointer is invalid. Option D/E: Not meaningful for member access. Common Pitfalls: Confusing `.` and `->`; taking addresses unnecessarily; aliasing concerns when switching active union members. Final Answer: Use `.` (or `->` with a pointer). `&` only obtains an address.

Question 3

Union layout in C: Must all members of a union have the same size, or can members differ in size with the union sized to fit the largest?

Accepted Answer

Introduction / Context: Unions provide a way to store different types in the same memory location. This question clarifies whether union members must be equal in size. Given Data / Assumptions: Standard C union with multiple members of varying sizes. Concept / Approach: C allows union members to have any size. The union’s size is at least the size of its largest member and may include extra padding for alignment. Therefore, equality of member sizes is not required. Step-by-Step Solution: 1) Identify largest member size among the union members. 2) Determine alignment requirements. 3) Compute union size as at least the largest member, possibly rounded for alignment. 4) Conclude members need not match sizes. Verification / Alternative check: Empirically check with `sizeof` on a sample union containing `char`, `int`, and `double`; member sizes differ, and union size follows the largest plus alignment. Why Other Options Are Wrong: Option B/D/E: No such rule in the C standard. Option C: Power-of-two restriction does not exist. Common Pitfalls: Assuming union behaves like a tagged variant automatically; forgetting to track which member is active; ignoring alignment when embedding unions in structs. Final Answer: Members may differ; union fits the largest (with alignment).

Question 4

Storage class defaults in C: If you declare a structure variable inside a block without an explicit storage-class specifier, what is its default storage duration?

Accepted Answer

Introduction / Context: C variables have storage duration depending on where and how they are declared. This question focuses on a structure variable declared inside a block with no storage-class specifier. Given Data / Assumptions: Declaration occurs inside a function block. No keywords like static, extern, or register are used. Concept / Approach: Local variables declared inside a block have automatic storage duration by default. They are created upon block entry and destroyed when the block is exited. This rule applies to any type, including structs. Step-by-Step Solution: 1) Place the declaration inside a function or compound statement. 2) Omit storage keywords; the default is automatic. 3) The object has block scope and automatic lifetime. 4) Contrast with file-scope declarations, which by default have static storage duration. Verification / Alternative check: Compile with a local struct variable and inspect lifetime via prints or address changes across calls; automatic objects get new storage each call unless declared static. Why Other Options Are Wrong: Option B: Static requires the static keyword or file scope. Option C: register is only a hint and not default. Option D: Thread storage uses _Thread_local or similar, not default. Option E: External linkage is about identifiers, not automatic lifetime. Common Pitfalls: Confusing storage duration (automatic vs static) with linkage and scope; assuming structs behave differently from scalars. Final Answer: Automatic storage duration for local (block-scope) struct variables.

Question 5

C typedef with struct tag reuse: Will the following declaration compile and work as intended, creating both a struct tag and a typedef of the same name?  typedef struct s {  int a;  float b; } s;

Accepted Answer

Introduction / Context: C maintains separate namespaces for struct/union/enum tags and for ordinary identifiers (including typedef names). This question clarifies whether a struct tag and a typedef may share the same spelling. Given Data / Assumptions: Declaration uses both a struct tag `s` and a typedef name `s` in the same statement. Concept / Approach: The code declares a tag named `s` and simultaneously introduces a typedef name `s` that aliases `struct s`. Because tags and typedef names are in different namespaces, this is valid and common in C. Afterward, you can write `s var;` instead of `struct s var;`. Step-by-Step Solution: 1) Parse the declaration: it defines `struct s { ... };`. 2) The trailing `} s;` introduces a typedef name `s` that refers to `struct s`. 3) The two uses of `s` live in different namespaces and do not conflict. 4) Using `s x;` now refers to the typedef type. Verification / Alternative check: Most codebases and textbooks demonstrate this idiom; it compiles cleanly on conforming C compilers. Why Other Options Are Wrong: Option B: Misinterprets namespaces; no redefinition here. Option C: Works in both C and C++. Option D/E: Member order or machine word size is irrelevant. Common Pitfalls: Confusing tag and typedef namespaces; thinking the second `s` shadows the first; assuming an ODR-like rule applies in C. Final Answer: Yes—valid and idiomatic; tag and typedef live in different namespaces.

Question 6

Flexible storage for names: Will the following C code allocate enough space for a variable-length name and print it correctly? #include #include struct emp { int len; char name[1]; }; int main() { char newname[] = "Rahul"; s…

Accepted Answer

Introduction / Context: This code demonstrates the pre-C99 “struct hack,” where a trailing one-element array is over-allocated to store variable-length data. Modern C (C99 and later) provides flexible array members, which are safer and standard-conforming. Given Data / Assumptions: Struct contains `int len;` and `char name[1];`. We allocate `sizeof(struct emp) - 1 + strlen(newname) + 1` bytes. We copy the string and print length and contents. Concept / Approach: The allocation subtracts the initial 1 byte already counted in `sizeof(struct emp)` and then adds the desired string length plus the null terminator, effectively creating room for the whole string inline after the struct header. This works on many compilers, but the standard approach is: struct emp { int len; char name[]; }; p = malloc(sizeof *p + strlen(newname) + 1); This avoids undefined-behavior concerns related to accessing beyond the declared array bounds and is well supported by C99+. Step-by-Step Solution: 1) Compute needed bytes: header + string length + 1 for terminator. 2) Allocate and set `p->len`. 3) Copy the string: `strcpy(p->name, newname);`. 4) Print: `printf("%d %s\n", p->len, p->name);`. 5) Prefer modern pattern with `char name[]` flexible member and `#include <stdlib.h>` for malloc/free. Verification / Alternative check: Compiles and runs on many systems; replacing with a flexible array member preserves intent and conformance while keeping logic and output identical. Why Other Options Are Wrong: Option B: It does work widely; the risk is standard conformance, not universal failure. Option C: `malloc.h` is obsolete; `stdlib.h` is correct and portable. Option D: `%ls` is for wide strings, which is unrelated. Option E: The over-allocation provides more space than the nominal `name[1]` declaration. Common Pitfalls: Forgetting to add space for the null terminator; using `malloc.h` instead of `stdlib.h`; not checking the return of `malloc`; assuming strict aliasing or padding rules that may differ across platforms. Final Answer: Yes on many compilers, but prefer the C99 flexible array member idiom for portable, standard-conforming code.

Question 7

In C programming, can we create a union whose members are pointers (for example, to allow the same storage to hold either an int* or a char*)? Choose the most accurate statement.

Accepted Answer

Introduction / Context: This question tests your understanding of what kinds of members a C union may contain. Many learners confuse unions with structs and sometimes believe pointer types are not allowed in unions. In reality, unions can contain almost any data member type permitted in C, including pointers, provided the members obey type and aliasing rules when accessed. Given Data / Assumptions: The topic is standard C (not C++), using ordinary hosted implementations. We are asking about a union whose members are pointer types (for example int* and char*). No compiler extensions are assumed or required. Concept / Approach: A union allocates a single block of storage large enough to hold its largest member. Any member may be read/written, but only the currently active one (the last written) has a defined value. The C standard places no restriction forbidding pointer members in a union. Therefore, defining union U { int *pi; char *pc; void *pv; }; is perfectly valid and common in systems code (for example, tagged variants or lightweight sum types). Step-by-Step Solution: Define a union with pointer members (e.g., int*, char*, void*). The union's size equals the maximum of the member pointer sizes (typically all equal). Assign to one member; reading the same bytes through another pointer member without an appropriate rationale is usually unspecified, but the act of defining the union is valid. Verification / Alternative check: You can compile a small program declaring such a union and print sizeof the union and its members; mainstream compilers (GCC/Clang/MSVC/Turbo C) accept it. Why Other Options Are Wrong: No: Incorrect; unions can have pointer members. Only in C++: Incorrect; C also supports this. Only if void*: Unnecessary; any pointer type is allowed. Compiler-specific: Not required; it is standard C. Common Pitfalls: Confusing “definition is allowed” with “reading through a different member is defined.” Storing via one member and reading via an incompatible one is generally unspecified; however, the union declaration itself is valid. Final Answer: Yes

Structures, Unions, Enums Questions