Language-Level Memory Management (C/C++/Rust) Questions

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).

The slowdown smells like cache-coherence overhead, especially false sharing. False sharing happens when threads update different variables that happen to live on the same cache line. A cache line is the unit of memory moved between cores, so even independent counters can fight each other if they sit next to each other in one shared struct.

How I would investigate:

• Profile CPU time and hardware counters for cache misses and coherence traffic.
• Inspect the status object layout to see whether per-thread counters are adjacent.
• Check for atomic read-modify-write operations, which can be expensive under contention.
• Verify the machine is not also hitting NUMA effects or memory bandwidth limits.

Concrete example: if 8 threads each increment a different int in one status object, and those ints fit on the same cache line, every increment can invalidate the line for the other cores. Adding more threads then makes the line bounce more, so throughput gets worse.

Typical fixes: give each thread its own counter, pad hot fields so they do not share a line, aggregate locally and publish less often, or move to thread-local storage. If the counters must be shared, I would try to reduce update frequency before I add more synchronization. When scaling gets worse with more cores, shared-memory traffic is usually the first thing I suspect.

I would raise three issues: alignment, strict aliasing, and endianness. Alignment means some CPUs require a uint32_t * to start on a 4-byte boundary. Strict aliasing means the compiler assumes pointers to unrelated types do not point to the same object, so casting a uint8_t * buffer and dereferencing it can miscompile under optimization. Endianness means byte order differs between CPUs.

A raw byte buffer is not automatically a real uint32_t object, so the safe pattern is to copy, not cast:

#include <stdint.h>
#include <string.h>

uint32_t word;
memcpy(&word, p, sizeof word);

Then convert from the protocol's byte order explicitly if needed. To prove the cast is not safe, I would test on a strict-alignment target, build with sanitizers or warnings like cast alignment, and compare the optimized build against the memcpy version. If behavior changes, the cast was relying on undefined behavior.

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.

The danger is that <= n touches one element past the valid range. In C, arr[n] is invalid when n is the count of valid elements. A pointer may be formed one-past-the-end, but dereferencing it is undefined behavior.

Concrete example: if arr has 4 elements and n = 4, the loop visits indices 0, 1, 2, 3, and then 4. At i == 4, a read may pull garbage from adjacent memory; a write may overwrite the next object or heap metadata. That is why the bug can appear much later as a crash in a totally different function.

It gets worse under optimization because undefined behavior gives the compiler permission to assume the bad access never happens. So the failure may look data-dependent or disappear in debug builds. The fix is i < n, and I would keep n as a size_t count so the loop matches the contract exactly.