What is the result of the following?
#define MIN(x,y) ((x)<(y)?(x):(y))
int a=5, b=3;
int result = MIN(a++, b++);
Answer: C
The macro expands to ((a++)<(b++)?(a++):(b++)). Since 5<3 is false, b++ is evaluated twice (once in comparison, once in ternary), making b=5. a is incremented once in comparison, so a=6.
Q.182Hard
What does the following preprocessor do?
#define OFFSET(type, field) ((size_t)&(((type *)0)->field))
Answer: A
This macro calculates the byte offset of a field within a structure by casting 0 as a pointer to the type and taking the address of the field. Similar to the offsetof() macro in stddef.h.
Q.183Hard
How many times is the argument evaluated in this macro?
#define CUBE(x) ((x)*(x)*(x))
int result = CUBE(a++);
Answer: C
The macro expands to ((a++)*(a++)*(a++)), so the argument a++ is evaluated 3 times. This demonstrates a critical problem with macros - side effects are repeated multiple times, leading to unexpected behavior.
Q.184Hard
What is a dangling macro problem in C?
Answer: C
A dangling macro typically refers to a macro that is defined but its usage may cause issues. More accurately, it's when a macro's scope or definition is unclear, especially in conditional compilation scenarios where #undef might cause problems.
Q.185Hard
Consider the following macro:
#define SWAP(a,b) {int temp=a; a=b; b=temp;}
What issue might occur with this macro?
Answer: D
While the macro works for all types (a and b are copied), the curly braces can cause issues when used in if-else statements without proper syntax (like missing semicolon after if). Additionally, it's limited to specific types. The safest answer is D regarding syntactic issues with placement.
Advertisement
Q.186Hard
What will happen if we define a macro with the same name as a C standard library function?
Answer: B
Macros are textual replacements that happen before compilation. If a macro has the same name as a library function, the macro replaces all occurrences of that name.
Q.187Hard
Consider the macro: #define AREA(r) 3.14*r*r
What is the issue and how to fix it?
Which of the following will correctly print the number of arguments passed to a variadic macro in C99?
Answer: A
C99 variadic macros don't have a built-in way to count arguments. Option A uses a clever technique with array size calculation. Option B references non-standard VA_NARGS. Options C and D use invalid syntax with token pasting.
Q.189Hard
Consider: #define SWAP(a,b) {int temp=a; a=b; b=temp;}
If used in an if-else without braces, which problem occurs?
if(condition) SWAP(x,y); else printf("No swap");
Answer: C
The macro expands to {int temp=a; a=b; b=temp;}; which ends with a semicolon. This creates: if(condition) {...}; else... The semicolon after the block makes else unreachable. The macro should use do-while(0) wrapper or be wrapped in a function.
Q.190Hard
What does the following preprocessor output?
#define VERSION "2024"
#define STR(x) #x
printf(STR(VERSION));
Answer: D
Stringification happens before macro expansion of arguments. STR(VERSION) becomes "VERSION" (a string literal of the token VERSION), not the value of VERSION. To stringify the expanded value, use indirect stringification with two levels of macros.
Q.191Hard
What will be the output of:
#define MAX(a,b) ((a)>(b)?(a):(b))
int main() { printf("%d", MAX(5++, 10)); return 0; }
Answer: C
The macro expands to ((5++)>(10)?(5++):(10)). The variable 5++ is evaluated multiple times due to macro substitution, causing undefined behavior. Increment operations in macro arguments should be avoided. This highlights why inline functions or constexpr functions are preferred in modern C++.
Q.192Hard
Which of the following will cause infinite recursion when used?
#define RECURSE() RECURSE()
Answer: C
The C preprocessor does not detect or prevent recursive macro expansion in its definition. RECURSE() will expand to RECURSE() infinitely, causing the preprocessor to hang or run out of memory. Modern compilers have safeguards, but theoretically this creates infinite expansion.
Q.193Hard
What will happen if a macro is defined multiple times with different definitions in the same compilation unit?
#define SIZE 10
#define SIZE 20
Answer: A
Redefining a macro with a different value in the same compilation unit causes a compilation error. To redefine, you must #undef first.
