DEV Community: Marcel

# Database Architecture: Implementing the Temporary File Pattern for Deletions in C

Marcel — Fri, 11 Sep 2026 15:34:59 +0000

When building a custom file-based database from scratch in raw C, you quickly hit a low-level hardware constraint: operating systems and storage controller drivers cannot natively delete a single line of text from the middle of a physical file on a disk drive.

To create a complete CRUD (Create, Read, Update, Delete) system for my contact book application, I had to implement a classic systems programming technique: the Temporary File Architectural Pattern.

This guide explains how database engines manipulate raw disk files to perform safe, non-destructive row deletions without corrupting adjacent data blocks.

The Architectural Limitation of Disk Storage

Unlike volatile RAM, where bytes can be modified dynamically at any specific memory address offset, data written to disk sectors is contiguous. If you open a text file stream in standard modify mode, you can overwrite existing bytes, but you cannot "squeeze" a line out and expect the remaining data to automatically shift upward to close the gap.

To execute a deletion, we have to fake it using a dual-stream filtering pipeline.

The Strategy: Read, Filter, and Rebuild

Instead of attempting to alter the original database file (contacts.txt) directly, the architecture relies on creating an isolated clone (temp.txt) that only inherits the data we want to keep.

The execution steps are straightforward:

Open the primary database file in Read ("r") mode.
Open a temporary storage file in Write ("w") mode.
Stream the primary file line-by-line into a stack-allocated character buffer.
Use a pattern matcher to inspect the string. If it matches the deletion query, the CPU drops the buffer. If it doesn't match, the stream writes the buffer directly into the temporary file.
Close both stream pipelines, wipe out the old file, and rename the temporary clone to become the new primary database.

Technical Implementation

Here is the robust abstraction layer handling the file stream operations safely:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int deleteContactRecord(const char *target_name) {
    // Open dual pipelines to the storage controller
    FILE *source_db = fopen("contacts.txt", "r");
    FILE *temp_db = fopen("temp.txt", "w");

    if (source_db == NULL || temp_db == NULL) {
        printf("System Error: Unable to initialize file database streams.\n");
        return 1;
    }

    char line_buffer[200];
    int deletion_flag = 0;

    // Stream lines into RAM row-by-row
    while (fgets(line_buffer, sizeof(line_buffer), source_db) != NULL) {
        // If the deletion query string is NOT found in this row, preserve it
        if (strstr(line_buffer, target_name) == NULL) {
            fprintf(temp_db, "%s", line_buffer);
        } else {
            deletion_flag = 1; // Match found; skip writing to filter it out
        }
    }

    // Force system flush and close connections
    fclose(source_db);
    fclose(temp_db);

    // Commit file table updates permanently
    if (deletion_flag == 1) {
        remove("contacts.txt");         // Erase the old database state
        rename("temp.txt", "contacts.txt"); // Promote temp file to primary
        printf("Record mapping to '%s' successfully purged.\n", target_name);
    } else {
        remove("temp.txt"); // Dissolve the empty utility file
        printf("Record not found. State preserved.\n");
    }

    return 0;
}

Why This Matters for Systems Engineering

This exact "read-filter-write" transaction pattern is the basics of database persistence.

With the CRUD engine of this app complete, the next architectural milestone is shifting from sequential file parsing to O(1) memory lookups by designing a custom Hash Table data structure from scratch.

c #programming #computerengineering #backend #database

# Demystifying the Stack: Why Passing Pointers to Local Structs Triggers Segfaults in C

Marcel — Thu, 10 Sep 2026 21:19:19 +0000

When transitioning from memory-managed languages like JavaScript to systems languages like C, the mental model of where variables live becomes critical. One of the most common architecture traps beginners and intermediate developers face is managing memory across function boundaries.

Specifically: attempting to manipulate or return pointers to local structures allocated on the stack.

This guide breaks down the physical mechanics of the stack, why direct pointer manipulation on local structs frequently causes segmentation faults, and how to safely handle stack data without crashing your application.

The Problem: Stack Frame Lifecycles

When you declare a struct inside a function locally (e.g., contact add_psn;), the compiler allocates that memory space within the current function's stack frame.

The fundamental rule of the stack is temporary existence: The moment that function execution hits a return statement, its stack frame is completely destroyed, and its memory space is reassigned.

If you create a pointer that points directly to that local structure, or if you attempt to pass a pointer of that local memory up or down the call stack improperly, you are creating a dangling pointer. The moment the parent function finishes, that pointer points to a completely unallocated, random memory address. Attempting to write to or read from it triggers an instant Segmentation Fault.

Case Study: Improper Stack Manipulation

Consider an application attempting to capture user input into a structural template directly on the stack:

#include <stdio.h>
#include <stdlib.h>

typedef struct {
    char name[100]; 
    char phone[12];
} contact;

// ARCHITECTURE FLAW: This function returns a pointer to a temporary stack variable
contact* addContactImproperly() {
    contact local_person; // Allocated on the stack frame of addContactImproperly

    // Simulate populating data
    local_person.name[0] = 'M';
    local_person.name[1] = '\0';

    // Returning the address of a local variable that is about to be destroyed
    return &local_person; 
}

int main() {
    contact *bad_pointer = addContactImproperly();

    // BUG: addContactImproperly's stack frame is gone. 
    // This line accesses illegal memory and causes a crash.
    printf("Name: %s\n", bad_pointer->name); 
    return 0;
}

The Engineering Solution: Pass by Reference (Down the Stack)

Instead of forcing a function to allocate memory locally and pass it up the stack, the standard, safe architectural pattern in systems programming is to allocate the structure in the caller function (main) and pass its memory address down by reference.

This ensures the memory lifecycle remains tied to the execution scope of the caller function.

#include <stdio.h>
#include <stdlib.h>

typedef struct {
    char name[100]; 
    char phone[12];
} contact;

// SAFE: This function operates directly on memory owned by the caller
void populateContactData(contact *target_destination) {
    // Accessing the struct directly via pointer dereferencing
    target_destination->name[0] = 'M';
    target_destination->name[1] = '\0';
}

int main() {
    // 1. Allocate the structure safely on the stack frame of main
    contact active_user; 

    // 2. Pass its address down. The memory is guaranteed to exist until main exits.
    populateContactData(&active_user); 

    // 3. Safe, crash-free execution
    printf("Successfully Retained Name: %s\n", active_user.name); 
    return 0;
}

Key Takeaway

When writing high-performance code or debugging embedded applications, mapping the exact boundary lines between stack allocation and heap allocation (malloc) prevents major memory leaks and segmentation bugs.

Always ensure your pointer's lifecycle never outlives the scope of the physical hardware block it points to.

c #programming #computerengineering #computerscience #softwarearchitecture

# Why I’m Embracing 21 Segfaults a Day at 17

Marcel — Wed, 09 Sep 2026 21:46:14 +0000

Today, I hit 21 segmentation faults in C.

Good day guys, my name is Marcel and I’m 17, living in Nigeria, and getting ready to study Computer Engineering at FUTO. I already have some experience with JavaScript and building SaaS apps (I actually spent part of my afternoon fixing a caching layout for my web app), but I’ve spent the last month diving deep into C.

And honestly? C is kicking my teeth in. But I love it.

Coming from JavaScript, memory is an abstract concept. You create an object, and the engine manages the hardware for you. In C, you are the manager. I am building a simple contact book project to handle creating a contact, saving it on a dedicated .txt file which gets loaded when users want to view their contact list and it also handles functions such as searching and deleting a contact. Today I was working on the header file that adds a contact and was having trouble allocating memory to store the user names e.g, (like my legal name, Izuoba Somtochukwu Marcel). Managing malloc and character buffers using raw loops felt like trying to defuse a bomb. One wrong index, and boom—Segmentation Fault.

Wrestling with the Input Buffer

Here is the exact single-user character loop I was battling today. I wanted to use %c so it would capture full names with spaces instead of cutting off like %s does, but I kept running into bugs where the loop would capture the leftover Enter key (\n) from previous inputs or loop infinitely:

#include <stdio.h>
#include <stdlib.h>

typedef struct {
    char name[100]; 
    char phone[12];
    char email[50]; 
} contact;

int addContact(void) {
    contact add_psn;
    char *c = malloc(100 * sizeof(char));
    if (c == NULL) return 1;

    // Clearing the invisible newline character stuck in the buffer
    char garbage;
    scanf("%c", &garbage);

    printf("Enter Name: ");
    int i;
    for (i = 0; i < 99; i++) {
        scanf("%c", &c[i]);

        // Break instantly when the user hits Enter so it doesn't hang!
        if (c[i] == '\n') {
            break;
        }
    }
    c[i] = '\0'; // Manually sealing the string

    for (int j = 0; j <= i; j++) {
        add_psn.name[j] = c[j]; 
    }

    printf("Saved Name: %s\n", add_psn.name);
    free(c);
    return 0;
}

The Shift From Code to Math

Later in the day, while studying finite mathematical induction, something clicked. In math, you prove a base case $P(1)$, assume $P(k)$ is true, and prove $P(k+1)$. When you write a loop like the one above—moving character-by-character through an input buffer—your brain is executing that exact inductive logic in physical hardware memory lanes.

Instead of waiting until I have physical ARM microcontrollers or hardware chips, I’m getting a head start entirely via software. I spent yesterday setting up PCB design simulation tools to practice building and routing boards right on my laptop. By writing my loops manually, handling the invisible newline characters trapped in the stream, and mastering pointers, I am learning exactly how software speaks to silicon before I ever print a physical board.

The Big Goal

People ask me why I’m bothering with raw C and low-level pointer arithmetic when I could just stick to high-level web frameworks.

The answer is simple: I want to help build a world-class automotive future for Africa. I’m actually a huge fan of Mercedes-Benz and hope to work with their engineering teams one day. But to build the smart, electric, and autonomous vehicles of the future, Africa cannot just rely entirely on imported Western or Asian chips. We need to develop our own domestic silicon architectures leveraging ARM instruction sets and high-performance functional cores like those of AMD.

To build a chip, you have to understand how code touches transistors. And to touch transistors, you have to survive the segmentation faults of C.

21 crashes today means 21 lessons learned. Tomorrow, we go again.

c, #beginners, #programming, #hardware.