Low Level Memory and Pointers Questions

Addresses low level memory concepts and pointer usage typical in languages such as C and C plus plus. Topics include stack versus heap semantics, pointer operations including dereferencing and pointer arithmetic, arrays of pointers, pointer to pointer usage, function pointers and callback patterns, pointer casting and aliasing, dynamic allocation and deallocation using functions such as malloc and free, common sources of memory leaks and dangling pointers, alignment and padding considerations, buffer overflows and undefined behavior, and tools and techniques for memory safety and debugging. Candidates should demonstrate safe pointer idioms, ownership reasoning, and approaches to detect and fix memory corruption and leaks.

HardTechnical

25 practiced

You are designing a C event-loop API that stores a callback and a user-data pointer for later invocation. The callback may run long after registration, and callers can unregister at any time. What rules or safeguards would you put in place so the callback does not dereference freed memory?

MediumTechnical

19 practiced

A parser builds a heap-allocated `char **` list of tokens and hands it to the caller. Some tokens are duplicated strings, and some are slices into a larger buffer. How would you design the ownership rules and cleanup path so the caller can safely filter or free the result without leaks or double frees?

Sample Answer

**Best design**I would not hand out a bare `char **` with mixed ownership and no metadata. I would return a small list object that carries the tokens plus one ownership flag per slot.

Rule: if `owned[i]` is true, the caller frees `items[i]`. If it is false, the token is a slice into the original buffer and must not be freed. The caller owns the container and releases it with one cleanup function that walks the list, frees only owned tokens, then frees the arrays.

Concrete example: token 0 could be `strdup("abc")` and token 1 could point into the input line `abc def`. If the caller filters out token 0, it frees that string, but leaves token 1 alone. I would also require the source buffer to stay alive until cleanup, or duplicate everything if I want the simplest contract.

for (size_t i = 0; i < list->len; ++i) {
    if (list->owned[i]) free(list->items[i]);
}
free(list->items);
free(list->owned);

MediumTechnical

19 practiced

Implement in C a function with this signature: `int append_int(int **data, size_t *len, size_t *cap, int value)`. It should grow a heap array when needed, preserve existing elements, and leave the original allocation unchanged if growth fails. Walk through the code or write it.

Sample Answer

To solve this, I would use `realloc` with a temporary pointer so a failed growth leaves the original array untouched. `realloc` is the standard resizing allocator: it may move the block, but on failure the old block is still valid.

#include <stdlib.h>
#include <stdint.h>

int append_int(int **data, size_t *len, size_t *cap, int value) {
    size_t new_cap;
    int *tmp;

    if (!data || !len || !cap || *len > *cap) return -1;

    if (*len == *cap) {
        new_cap = (*cap == 0) ? 4 : (*cap * 2);
        if (new_cap < *cap) return -1;
        if (new_cap < *len + 1) new_cap = *len + 1;
        if (new_cap > SIZE_MAX / sizeof(int)) return -1;

        tmp = realloc(*data, new_cap * sizeof(int));
        if (!tmp) return -1;

        *data = tmp;
        *cap = new_cap;
    }

    (*data)[*len] = value;
    (*len)++;
    return 0;
}

Example: if `len = 3` and `cap = 4`, appending `9` stores it at index 3 with no resize. If `len = 4` and `cap = 4`, the function grows to 8, preserves the first 4 integers, and only then appends. Time is amortized O(1), with O(n) work only on resize.

MediumTechnical

21 practiced

Write a C function that removes every node with a target value from a singly linked list and returns the new head. The implementation should free removed nodes correctly and handle deleting the first node without special-case bugs.

Sample Answer

**A pointer-to-pointer loop makes this clean.** The key idea is that `cur` always points to the link that leads to the current node, so deleting the head uses the same code as deleting any other node.

#include <stdlib.h>

struct Node {
    int value;
    struct Node *next;
};

struct Node *remove_all(struct Node *head, int target) {
    struct Node **cur = &head;

    while (*cur) {
        if ((*cur)->value == target) {
            struct Node *dead = *cur;
            *cur = dead->next;
            free(dead);
        } else {
            cur = &(*cur)->next;
        }
    }

    return head;
}

Concrete example: for `5 -> 2 -> 2 -> 7` with target `2`, the function frees both matching nodes and returns `5 -> 7`. Time is O(n), space is O(1).

MediumTechnical

24 practiced

A loop like `for (int i = 0; i <= n; ++i)` was merged into a C code path where `n` is the number of valid array elements. The code sometimes works in testing and sometimes crashes in production. What makes this pattern dangerous in C, and how can it turn into a harder-to-debug memory bug than a simple out-of-bounds read?

Unlock Full Question Bank

Get access to hundreds of Low Level Memory and Pointers interview questions and detailed answers.

Join thousands of developers preparing for their dream job.