C interview questions

What a strong answer covers

• Define pointer arithmetic as operations on memory addresses, where adding/subtracting an integer moves the pointer by that many *elements* of its base type.
• Explain that `ptr + n` moves the pointer `n * sizeof(*ptr)` bytes in memory.
• Provide a clear code example using an `int` array and an `int*` pointer to iterate through or access elements.
• Mention common valid operations (addition/subtraction of integers, subtraction of two pointers of the same type) and invalid ones (multiplication, division, addition of two pointers).
• Discuss the importance of type safety and bounds checking to prevent undefined behavior.

Where people lose the point

• ×Assuming pointer arithmetic operates on bytes directly, rather than element sizes.
• ×Forgetting that subtracting two pointers yields the number of elements between them, not bytes.
• ×Failing to mention the dangers of out-of-bounds access and undefined behavior.

What a strong answer covers

• Explain `malloc()` as a function to allocate a block of memory of a specified size (in bytes) from the heap at runtime, returning a `void*` pointer to the beginning of the block.
• Explain `free()` as a function to deallocate memory previously allocated by `malloc`, `calloc`, or `realloc`, returning it to the heap.
• Discuss use cases: dynamic data structures (linked lists, trees), handling data of unknown size at compile time, and avoiding stack overflow for large allocations.
• Detail common pitfalls: memory leaks (forgetting to `free`), dangling pointers (accessing freed memory), double-freeing, and failing to check `malloc()`'s return value for `NULL`.

Where people lose the point

• ×Not mentioning the need to cast `malloc`'s `void*` return value to the appropriate type.
• ×Forgetting to emphasize the importance of checking for `NULL` return from `malloc`.
• ×Confusing heap memory with stack memory and their respective lifetimes.

What a strong answer covers

• Define 'pass by value' as passing a copy of the argument's value to the function, meaning changes inside the function do not affect the original variable.
• Provide a simple code example demonstrating pass by value (e.g., a function that tries to increment an integer).
• Define 'pass by reference' (simulated in C using pointers) as passing the memory address of the argument, allowing the function to modify the original variable through dereferencing the pointer.
• Provide a simple code example demonstrating pass by reference (e.g., a function that increments an integer using a pointer).
• Discuss the implications and typical use cases for each method (e.g., pass by value for simple data, pass by reference for modifying multiple values or large data structures).

Where people lose the point

• ×Incorrectly stating that C has true 'pass by reference' like C++ (it simulates it with pointers).
• ×Failing to provide clear, working code examples for both scenarios.
• ×Not explaining *why* one would choose one method over the other.

What a strong answer covers

• Explain `static` for local variables: extends their lifetime to the entire program execution, but keeps their scope limited to the function/block where they are declared (e.g., a counter that persists across function calls).
• Explain `static` for global variables and functions: limits their scope to the file in which they are declared, preventing external linkage and name clashes across multiple source files.
• Provide distinct code examples for `static` local variables and `static` global variables/functions.
• Discuss the benefits: data persistence without global scope, encapsulation, and preventing unintended external modification.

Where people lose the point

• ×Confusing `static`'s effect on lifetime with its effect on scope (e.g., thinking a static local variable is globally accessible).
• ×Not providing separate examples for its different contexts (local vs. global/function).
• ×Failing to mention its role in information hiding and modularity.

What a strong answer covers

• Define `const` as a type qualifier that indicates a variable's value cannot be changed after initialization, enforcing read-only access.
• Explain `const` with variables: `const int x = 10;` makes `x` immutable.
• Explain `const` with pointers: differentiate between `const int *ptr` (pointer to a constant integer, data cannot be changed through `ptr`) and `int *const ptr` (constant pointer to an integer, `ptr` cannot be reassigned to point elsewhere).
• Explain `const` with function parameters: used to guarantee that a function will not modify the argument passed by pointer, improving safety and clarity (e.g., `void print_array(const int *arr, int size)`).
• Discuss the benefits: compile-time error checking, improved code readability, and enabling compiler optimizations.

Where people lose the point

• ×Confusing `const int *ptr` with `int *const ptr` and their respective immutability.
• ×Not explaining how `const` applies to function parameters for safety.
• ×Believing `const` variables are stored in read-only memory (not always true, depends on context and compiler).

What a strong answer covers

• Define `struct` as a user-defined data type that groups variables of different types under a single name, with each member occupying its own distinct memory location.
• Define `union` as a user-defined data type that can hold members of different types, but all members share the *same* memory location, meaning only one member can be active at any given time.
• Illustrate memory allocation differences: `sizeof(struct)` is sum of members (plus padding), `sizeof(union)` is size of its largest member.
• Discuss use cases: `struct` for representing complex objects with multiple distinct attributes, `union` for memory optimization when only one piece of data is relevant at a time (e.g., variant types, network packet headers).
• Highlight the importance of careful management with `union` to avoid reading invalid data (e.g., using a tag field in a `struct` containing a `union`).

Where people lose the point

• ×Incorrectly stating that `union` members have separate memory locations.
• ×Failing to explain the memory efficiency aspect of `union`.
• ×Not mentioning the potential for data corruption if `union` is used without tracking the active member.

What a strong answer covers

• Define preprocessor macros as text substitutions performed by the preprocessor before compilation, using `#define`.
• Explain advantages: code reuse, symbolic constants, conditional compilation, creating 'inline' functions (though `inline` keyword is preferred for functions).
• Explain disadvantages: lack of type checking, potential for unintended side effects (e.g., multiple evaluation of arguments), operator precedence issues, and difficulty in debugging.
• Provide an example of a common pitfall, such as ` #define SQUARE(x) x*x ` leading to `SQUARE(a+b)` expanding to `a+b*a+b` instead of `(a+b)*(a+b)`.
• Suggest best practices like using parentheses around macro arguments and the entire macro definition to mitigate precedence issues.

Where people lose the point

• ×Confusing macros with functions and not highlighting the lack of type safety.
• ×Failing to provide a concrete example of a macro pitfall.
• ×Not mentioning the `inline` keyword as a safer alternative for function-like macros.

What a strong answer covers

• Define a dangling pointer as a pointer that points to a memory location that has been deallocated or is no longer valid.
• Explain common scenarios leading to dangling pointers: `free()`ing memory that a pointer points to, returning the address of a local stack variable from a function, or going out of scope for a local variable.
• Discuss potential consequences: undefined behavior, segmentation faults, data corruption, security vulnerabilities (use-after-free exploits).
• Suggest mitigation strategies: setting pointers to `NULL` after `free()`, ensuring pointers don't outlive their target memory, and careful scope management.

Where people lose the point

• ×Confusing dangling pointers with `NULL` pointers (a `NULL` pointer is safe, a dangling pointer is not).
• ×Not providing concrete examples of how dangling pointers arise (e.g., `free` then access, returning address of local variable).
• ×Understating the severity of undefined behavior caused by dangling pointers.

What a strong answer covers

• Define a `void` pointer (`void *`) as a generic pointer that can point to any data type without knowing the type of data it points to.
• Explain its utility: used for generic memory management functions (`malloc`, `free`), generic data structures (e.g., linked lists storing `void*`), and interfacing with untyped memory blocks.
• Discuss limitations: `void` pointers cannot be dereferenced directly (must be cast to a specific type first), and pointer arithmetic is not directly allowed on `void` pointers (as `sizeof(void)` is undefined).
• Provide an example demonstrating its use, such as `malloc` returning `void*` or a generic swap function.

Where people lose the point

• ×Attempting to dereference a `void*` without casting it first.
• ×Trying to perform pointer arithmetic directly on a `void*`.
• ×Not explaining *why* `void*` is useful for generic programming.

What a strong answer covers

• Describe stack memory: automatically managed, LIFO (Last-In, First-Out), used for local variables, function call frames, and return addresses. Allocation/deallocation is fast.
• Describe heap memory: dynamically managed, programmer-controlled, used for data whose size is unknown at compile time or needs to persist beyond a function's scope. Allocation/deallocation is slower.
• Explain allocation methods: stack uses automatic allocation (variable declarations), heap uses `malloc`/`calloc`/`realloc` and `free`.
• Discuss typical use cases: stack for small, temporary data; heap for large data structures, global data, or data requiring flexible lifetimes.
• Mention potential issues: stack overflow (too much recursion or large local arrays), memory leaks/fragmentation on the heap.

Where people lose the point

• ×Confusing automatic management of the stack with manual management of the heap.
• ×Incorrectly stating that stack memory is slower than heap memory.
• ×Failing to mention stack overflow as a common stack-related issue.

What a strong answer covers

• Define a memory leak as a situation where a program allocates memory from the heap but fails to deallocate it when it's no longer needed, making that memory inaccessible for future use.
• Explain common causes: forgetting to call `free()` for `malloc()`ed memory, losing the pointer to allocated memory (e.g., reassigning a pointer without freeing the old block), or errors in error handling paths.
• Discuss consequences: gradual consumption of available RAM, leading to performance degradation, system instability, and eventual program or system crash.
• Suggest prevention strategies: always pair `malloc()` with `free()`, use smart pointers (in C++ context, but mention careful pointer ownership in C), robust error handling, and using memory profiling tools (e.g., Valgrind).

Where people lose the point

• ×Confusing memory leaks with dangling pointers or segmentation faults.
• ×Not emphasizing the cumulative nature of memory leaks.
• ×Failing to mention tools or systematic approaches for detection and prevention.

What a strong answer covers

• **Preprocessing:** Explain that the preprocessor handles directives like `#include`, `#define`, and conditional compilation. It expands macros, includes header files, and removes comments, producing an expanded source file (`.i` extension).
• **Compilation:** Describe this phase as the translation of the preprocessed source code into assembly language. This involves syntax checking, semantic analysis, and optimization, producing an assembly file (`.s` extension).
• **Assembly:** Explain that the assembler translates the assembly code into machine code, creating an object file (`.o` extension). This file contains machine instructions but is not yet executable as it may have unresolved external references.
• **Linking:** Detail the linker's role in combining one or more object files with necessary library files (static or dynamic) to resolve all external references and create a single, executable program.
• Discuss how each phase contributes to the final executable and how errors at each stage manifest.

Where people lose the point

• ×Skipping one of the phases or misordering them.
• ×Not clearly explaining what each phase *does* and what its output is.
• ×Confusing the compiler's role with the linker's role, especially regarding external references.

What a strong answer covers

• Define `volatile` as a type qualifier that tells the compiler that a variable's value can be changed by something outside the normal flow of the program (e.g., hardware, another thread, an interrupt service routine).
• Explain its purpose: to prevent the compiler from optimizing away reads or writes to the variable, ensuring that every access to a `volatile` variable is performed as specified in the source code.
• Provide common use cases: memory-mapped I/O registers, global variables modified by interrupt service routines, and global variables shared between multiple threads (though `volatile` alone is not sufficient for thread safety).
• Illustrate with an example where `volatile` would be crucial (e.g., polling a hardware status register in a loop).
• Emphasize that `volatile` does *not* guarantee atomicity or thread safety; it only affects compiler optimization.

Where people lose the point

• ×Confusing `volatile` with `const` or `static`.
• ×Believing `volatile` makes operations atomic or thread-safe.
• ×Not providing concrete scenarios where `volatile` is essential.

What a strong answer covers

• Define `extern` as a storage class specifier that declares a variable or function, indicating that its definition exists elsewhere (in another source file or later in the current file).
• Explain its primary use: to allow multiple source files to share global variables and functions, facilitating modular programming.
• Provide an example: declaring `extern int global_var;` in one file to access `global_var` defined in another file.
• Differentiate between declaration (using `extern`) and definition (where memory is allocated and initialized). `extern` provides a declaration without a definition.
• Discuss how it works with the linker to resolve references to symbols defined in other compilation units.

Where people lose the point

• ×Confusing `extern` with `#include` (one declares, the other copies text).
• ×Attempting to initialize an `extern` variable in its declaration (unless it's also its definition).
• ×Not understanding that `extern` is about linkage, not scope.

What a strong answer covers

• Define a buffer overflow as a condition where a program attempts to write data beyond the allocated boundary of a fixed-size buffer, overwriting adjacent memory locations.
• Explain common causes: using unsafe string manipulation functions (`strcpy`, `strcat`, `sprintf`) without bounds checking, or incorrect loop conditions when writing to arrays.
• Discuss potential consequences: program crashes (segmentation faults), data corruption, and severe security vulnerabilities (e.g., executing arbitrary code by overwriting return addresses on the stack).
• Suggest prevention methods: using bounds-checked functions (`strncpy`, `strncat`, `snprintf`), dynamic memory allocation, input validation, and compiler-level protections (stack canaries).
• Provide a simple code example demonstrating a vulnerable `strcpy` usage.

Where people lose the point

• ×Underestimating the security implications of buffer overflows.
• ×Not mentioning specific unsafe functions or their safer alternatives.
• ×Failing to explain *how* overwriting memory can lead to code execution.

What a strong answer covers

• Define a function pointer as a variable that stores the memory address of a function, allowing functions to be called indirectly.
• Explain declaration syntax: `return_type (*pointer_name)(parameter_list);` (e.g., `int (*op_func)(int, int);`).
• Explain initialization: assigning the name of a function (which decays to its address) to the function pointer (e.g., `op_func = &add;` or `op_func = add;`).
• Explain usage: calling the function through the pointer (e.g., `result = (*op_func)(a, b);` or `result = op_func(a, b);`).
• Provide a practical example: implementing a simple callback mechanism, a generic sort function, or a jump table for a menu-driven program.

Where people lose the point

• ×Incorrectly declaring or initializing a function pointer (e.g., missing parentheses around `*pointer_name`).
• ×Not providing a clear, practical use case beyond just syntax.
• ×Confusing function pointers with regular pointers to data.