Question bank — Dynamic memory — malloc, calloc, realloc, free

False. malloc returns uninitialized (garbage) bytes; only calloc guarantees zeros. Fresh pages may look zeroed by luck of the OS, but reused heap memory holds old contents.

False. free returns the block to the allocator but does not touch your pointer variable; p still holds the same (now dangling) address. You must set p = NULL; yourself.

False. Calling free(NULL) is explicitly defined as a harmless no-op by the C standard, which is exactly why nulling a pointer after freeing makes an accidental second free safe.

False. Overflow checking in calloc is implementation-defined. Glibc, musl, etc. do check in practice, but a conforming minimal libc need not — so treat it as a bonus, not a portable guarantee.

False. realloc(NULL, n) is defined to behave exactly like malloc(n). This lets you write generic grow-loops that work even on the first call when the pointer is still NULL.

False (subtle). It may free p, but whether it returns NULL or a tiny valid pointer is implementation-defined. Don't rely on the return value to mean "freed" — use free for freeing.

False. Only stack (automatic) variables vanish at function return. Heap blocks live until you free them or the program exits — see The Stack and the Heap.

False. malloc returns exactly NULL on failure; there is no "invalid non-null" sentinel. That's why a single if (p == NULL) check is sufficient.

False. sizeof(*p) is the size of the object p points to (one element); sizeof(p) is the size of the pointer itself (typically 8 bytes on 64-bit). Confusing them under-allocates — see sizeof operator.

False. Adding one forces a copy on nearly every push, giving $O(n^2)$ total work. Doubling gives $O(n)$ amortized because copies become geometrically rare.

Under-allocation. You asked for n bytes but store n ints — you need n * sizeof(*p) bytes. Writing past the block is buffer overflow and Undefined Behavior in C.

Double free. The second free(p) corrupts the allocator's bookkeeping. Fix: free(p); p = NULL; so a repeat call becomes the harmless free(NULL).

Self-assign leak. If realloc fails it returns NULL but keeps the old block alive — you just overwrote its only pointer, leaking it. Use a temporary and commit only on success.

Off-by-one. strlen excludes the terminating '\0', so the copy writes one byte past the block. You need strlen(t) + 1.

Stray semicolon. The if has an empty body, so return -1 runs unconditionally — and if you removed the semicolon you'd still leak by returning before free. The logic and cleanup are both broken.

Use-after-free. After free, the block may already be reissued to another allocation; writing to it is Undefined Behavior in C even though the pointer bits look unchanged.

Negative count wraps. calloc's parameters are size_t (unsigned), so -1 becomes a huge value; the call almost certainly returns NULL, and if you skip the null check you'll crash on first use.

Leak. The second call overwrites g, dropping the first block's only pointer with no free — a classic leak that Memory Leaks and Valgrind would flag.

Because sizeof(*p) tracks p's type automatically. If you later change p from int* to long*, this line stays correct with no edit — it removes a whole class of bugs.

The heap can be exhausted, in which case malloc returns NULL; dereferencing NULL is undefined behavior and typically a crash. Checking turns a silent disaster into a controlled failure path.

It splits size into count and size so the library performs the multiplication — giving it the chance to detect overflow of that product and return NULL (on most, though not all, implementations).

On failure realloc returns NULL but the old block is still valid. Assigning into a tmp first preserves the original pointer so you can free it cleanly instead of leaking it.

A freed pointer is dangling — it aims at reclaimed memory. Nulling it turns an accidental reuse into a clean crash instead of silent corruption, and makes any repeat free a safe no-op.

Stack frames are sized and freed automatically at compile/scope boundaries and have limited size; the heap gives you memory whose amount and lifetime you control at runtime — the whole point per Arrays vs Pointers.

Each copy costs the current length, but doubling makes copies happen only $O(\log n)$ times over $n$ pushes, so total copy work sums to $O(n)$ amortized rather than $O(n^2)$.

Implementation-defined: either NULL or a unique non-null pointer that you may not dereference but must still free. Never assume it's non-null and usable.

Undefined behavior — free may only receive a pointer returned by malloc/calloc/realloc (or NULL). Passing anything else corrupts the allocator.

No. You must free the exact pointer the allocator gave you, not an interior or offset pointer. Freeing a shifted address is undefined behavior.

No. When realloc relocates data, every previously saved pointer (and index cached as an address) into the old block becomes dangling. Only the newly returned pointer is valid afterward.

Technically the OS reclaims all memory at process exit, so a one-shot leak is harmless — but in long-running or looping code it accumulates and is still a real bug that Memory Leaks and Valgrind will report.

Yes. Shrinking is allowed; the first n bytes are preserved and the tail is released. The returned pointer may differ, so still assign it back via a temporary.