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

What is happening is a use-after-return. The local array lives on the stack, and that stack frame is destroyed when the function returns. The struct keeps a pointer to memory that no longer belongs to it, so the next read can see overwritten stack data or crash outright.

In code review, I would look for any address of a local variable or local array being stored into a field that escapes the function, especially if the function returns that struct. A line like s.buf = tmp; where tmp is char tmp[32]; is the red flag.

The API rule I would change is ownership: either the struct owns heap memory and provides a destroy function, or it clearly borrows memory that must outlive the struct. Mixing the two is the bug. For a returned struct, I would prefer deep-copying the data into owned storage and documenting that the caller must free it later.

Concrete example: char tmp[16] is valid only inside the function. After return, s.buf points into dead stack space, so reading s.buf[0] is undefined behavior.

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

For one producer and one consumer, I would use a fixed-size ring buffer. That is a circular array where the producer writes at tail and the consumer reads at head. It fits the latency goal because there are no dynamic allocations after startup.

Invariants I would preserve:

• head and tail only move forward modulo capacity.
• The producer never overwrites an unread slot.
• The consumer never reads a slot before it is published.
• Each slot holds either an empty state or exactly one live object.

Synchronization choices:

• Make head and tail atomics.
• The producer writes the element first, then publishes the new tail with release semantics.
• The consumer reads tail with acquire semantics before consuming the element.
• Pad head and tail so they do not share a cache line, which avoids false sharing.

Concrete example: with capacity 1024, if head = 17 and tail = 18, slot 17 is valid for the consumer. The producer writes to slot 18, then stores tail = 19. That store is the signal that the data is ready.

Memory-safety issues to watch: object lifetime, destructor calls for non-trivial types, full and empty detection, and not using volatile as a substitute for synchronization. In interviews, I would call this the standard SPSC queue design, and it is usually the best low-latency answer.

I would reason from layout, not from what happens to work on one machine. A C struct has an order, an alignment, padding, and a type size on a specific ABI. Alignment is the byte boundary a type prefers, and padding is extra space the compiler inserts so members land on valid boundaries.

Example: struct { uint8_t tag; uint32_t len; } often occupies 8 bytes, not 5. len usually starts at offset 4, so there are 3 padding bytes after tag. A 5-byte binary message will not match that memory layout. Endianness also matters: the same 4 bytes mean different numbers on little-endian and big-endian CPUs.

For direct I/O parsing, I would use a struct only if the wire format is explicitly defined to match that ABI, and I would verify it with sizeof, offsetof, and _Static_assert. In most portable code, I would parse from bytes with memcpy or shifts instead of casting raw input into a struct. Packed structs are a last resort because they can create unaligned accesses.

The first thing I would check is whether file descriptors are being closed on the correct side of the fork. A pipe only reaches EOF when every write end is closed. If the parent keeps a write end open, the child can block forever waiting for input or the parent can block waiting for output that never finishes.

Common OS-level mistakes:

• Forgetting to close the unused pipe ends in both parent and child.
• Calling dup2, but not closing the original descriptor afterward.
• Not setting close-on-exec, so descriptors leak into the exec'd program or its children.
• Using one pipe for two-way communication instead of separate pipes.
• Waiting for the child before draining its stdout, which can deadlock if the pipe buffer fills.

Concrete example: if the parent creates pipe fds 3 and 4, the child should dup2(3, STDIN_FILENO), close 3, and close 4. The parent should close 3 immediately, and close 4 when it is done writing. If 4 stays open anywhere, the reader may never see EOF.

How I would debug it: trace fork, dup2, close, and exec, then inspect open descriptors with /proc or lsof. Most hangs of this kind are not mysterious OS bugs, just one leaked file descriptor keeping the pipe alive.