Which of the following will cause infinite recursion when used?
#define RECURSE() RECURSE()
AIt will cause stack overflow at runtime
BThe preprocessor detects recursion and stops expansion
CIt will expand infinitely, causing preprocessor to hang
DIt will cause compilation error
Correct Answer:
C. It will expand infinitely, causing preprocessor to hang
EXPLANATION
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.
What will be the output of:
#define MAX(a,b) ((a)>(b)?(a):(b))
int main() { printf("%d", MAX(5++, 10)); return 0; }
A10
B11
CUndefined behavior
D6
Correct Answer:
C. Undefined behavior
EXPLANATION
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++.
What does the following preprocessor output?
#define VERSION "2024"
#define STR(x) #x
printf(STR(VERSION));
A2024
BVERSION
C"2024"
D"VERSION"
Correct Answer:
D. "VERSION"
EXPLANATION
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.
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");
ANo problem, it will work correctly
BSyntax error during compilation
CThe else statement becomes unreachable
DThe macro cannot be used in conditional statements
Correct Answer:
C. The else statement becomes unreachable
EXPLANATION
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.
Correct Answer:
A. #define COUNT_ARGS(...) sizeof((int[]){__VA_ARGS__})/sizeof(int)
EXPLANATION
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.
What will happen if we define a macro with the same name as a C standard library function?
ACompilation error
BThe macro replaces the function everywhere
CRuntime error
DNo effect, function takes precedence
Correct Answer:
B. The macro replaces the function everywhere
EXPLANATION
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.
Consider the following macro:
#define SWAP(a,b) {int temp=a; a=b; b=temp;}
What issue might occur with this macro?
AWorks perfectly for all data types
BOnly works for integers, fails for other types like float
CRequires variables to be initialized before use
DThe curly braces prevent use inside if-else statements without care
Correct Answer:
D. The curly braces prevent use inside if-else statements without care
EXPLANATION
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.
BA macro whose definition contains unmatched parentheses
CA macro that is defined but later undefined without being used properly
DA macro that causes infinite recursion during preprocessing
Correct Answer:
C. A macro that is defined but later undefined without being used properly
EXPLANATION
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.
