File Handling in C — 'w' Mode Truncated Our Logs

Every meaningful program eventually needs to outlive itself. A configuration it reads on startup, a log it writes during a crash, a CSV it exports for a client — none of that works if data only lives in RAM. File handling is the bridge between your program's fleeting in-memory world and the persistent world on disk. That's not a nice-to-have feature; it's table stakes for anything production-grade.

The C standard library solves this with a thin but powerful abstraction: the FILE pointer. Instead of dealing with raw OS system calls (which differ between Linux, Windows, and macOS), you get a portable, consistent API — fopen, fread, fwrite, fprintf, fscanf, fclose — that works identically everywhere C runs. The OS complexity is hidden behind that single FILE* handle, which is exactly why C file I/O has survived for fifty years without being replaced.

By the end of this article you'll be able to open files safely, read and write both text and binary data, handle errors the way real production code does, and avoid the three mistakes that trip up even experienced developers. You'll also walk away with the conceptual model that makes every fread/fwrite call feel obvious rather than magical.

What File Handling in C Actually Does — and Why 'w' Mode Destroys Your Data

File handling in C is the set of standard library functions (fopen, fclose, fprintf, fscanf, etc.) that allow a program to read from and write to persistent storage via a FILE* stream. The core mechanic is that fopen returns a pointer to a FILE structure that holds the stream state, buffer, and file descriptor; you then use that pointer for all subsequent I/O operations until fclose flushes the buffer and releases the resource.

In practice, the mode string you pass to fopen determines the initial state of the file pointer and whether the file is truncated or appended. 'w' opens the file for writing, creates it if it doesn't exist, and — critically — truncates the file to zero length immediately upon success. This happens before your first fprintf call. There is no undo. The file's previous content is gone the moment fopen returns. 'a' (append) does not truncate; 'r+' opens for read/write without truncation but requires the file to exist.

Use 'w' only when you intend to replace the entire file content from scratch — for example, writing a fresh configuration file or a new log file per run. Never use 'w' for appending logs, updating records in place, or any scenario where existing data must survive. In production systems, a single 'w' where 'a' was intended can silently erase hours of critical log data, making this one of the most common and costly C I/O mistakes.

Opening and Closing Files — The FILE* Lifecycle You Must Respect

Every file operation in C starts with fopen() and must end with fclose(). The FILE* pointer you get back isn't a file — it's a control structure the C runtime uses to buffer data, track your position, and manage the connection to the OS file descriptor. Think of it as a library card: you need it to check out books, and you must return it when you're done.

fopen() takes two arguments: the file path and a mode string. The mode tells the OS what you intend to do — 'r' for reading an existing file, 'w' for writing (creating or truncating), 'a' for appending, and their binary variants 'rb', 'wb', 'ab'. Choosing the wrong mode is one of the most common sources of data loss in C programs.

fopen() returns NULL on failure — network drive unavailable, wrong permissions, file doesn't exist in 'r' mode. You must check for NULL before doing anything else. Skipping that check is not a style issue; it's a segfault waiting to happen. Always pair your NULL check with perror() so the error message tells you exactly what went wrong, not just that something did.

#include <stdio.h>
#include <stdlib.h>  // for exit()

int main(void) {
    // Attempt to open (or create) a log file for writing
    // 'w' mode: creates the file if it doesn't exist,
    //           TRUNCATES it to zero bytes if it does — be careful!
    FILE *log_file = fopen("app_log.txt", "w");

    // ALWAYS check for NULL before using the pointer.
    // fopen returns NULL when the file can't be opened for any reason.
    if (log_file == NULL) {
        // perror prints the system error message (e.g. "Permission denied")
        // prefixed by whatever string you pass it.
        perror("ERROR: Could not open app_log.txt");
        exit(EXIT_FAILURE);  // exit cleanly rather than crash later
    }

    // Write a header line to the log
    fprintf(log_file, "=== Application Log Started ===\n");
    fprintf(log_file, "Status: Initialised successfully\n");

    // fclose flushes any buffered data to disk AND releases the FILE*
    // resource. Skip this and you may lose the last chunk of data.
    if (fclose(log_file) != 0) {
        perror("ERROR: Could not close app_log.txt");
        exit(EXIT_FAILURE);
    }

    printf("Log written successfully. Check app_log.txt\n");
    return 0;
}

Reading and Writing Text Files — fprintf, fscanf, fgets in Practice

Text file I/O is the most common form of file handling you'll write. Configuration files, CSV exports, log files, INI parsers — they're all text. C gives you three main tools: fprintf/fscanf (formatted, mirrors printf/scanf), fgets (line-by-line reading, the safe choice), and fputc/fgetc (character by character, useful for parsers).

fscanf looks tempting but has a reputation for being fragile — it stops at whitespace, which means names with spaces silently break it. fgets is almost always the better choice for reading: it reads an entire line up to a newline or the buffer limit, whichever comes first, so it never overflows your buffer (unlike gets, which was removed from C11 for that exact reason).

The pattern for reading a text file line by line is a while loop with fgets as the condition. When fgets hits end-of-file it returns NULL, ending the loop cleanly. Inside the loop you can parse, tokenise, or process each line however you need. This pattern powers everything from simple config readers to lightweight CSV parsers in embedded systems.

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

#define MAX_LINE_LENGTH 256
#define SCORES_FILE     "scores.txt"

// Writes three player scores to a text file
void write_scores(void) {
    FILE *scores_file = fopen(SCORES_FILE, "w");
    if (scores_file == NULL) {
        perror("ERROR: Cannot create scores file");
        exit(EXIT_FAILURE);
    }

    // fprintf works exactly like printf but targets a file
    fprintf(scores_file, "Alice,4200\n");
    fprintf(scores_file, "Bob,3875\n");
    fprintf(scores_file, "Charlie,5100\n");

    fclose(scores_file);
    printf("Scores written to %s\n", SCORES_FILE);
}

// Reads every line back and prints it with a rank number
void read_scores(void) {
    FILE *scores_file = fopen(SCORES_FILE, "r");
    if (scores_file == NULL) {
        perror("ERROR: Cannot open scores file for reading");
        exit(EXIT_FAILURE);
    }

    char line_buffer[MAX_LINE_LENGTH];  // holds one line at a time
    int rank = 1;

    printf("\n--- Leaderboard ---\n");

    // fgets reads up to (MAX_LINE_LENGTH - 1) chars, stops at '\n' or EOF.
    // It returns NULL when there's nothing left to read.
    while (fgets(line_buffer, sizeof(line_buffer), scores_file) != NULL) {
        // fgets keeps the trailing '\n' — strip it for clean display
        line_buffer[strcspn(line_buffer, "\n")] = '\0';

        // strtok splits the line on the comma delimiter
        char *player_name  = strtok(line_buffer, ",");
        char *score_string = strtok(NULL, ",");

        if (player_name != NULL && score_string != NULL) {
            printf("  #%d  %-10s  %s pts\n", rank++, player_name, score_string);
        }
    }

    fclose(scores_file);
}

int main(void) {
    write_scores();
    read_scores();
    return 0;
}

Binary File I/O — fread and fwrite for Structs and Raw Data

Text files are human-readable but inefficient for structured data. If you're storing a thousand employee records, writing each integer as a string of ASCII digits wastes space and requires parsing on the way back in. Binary mode writes the raw bytes from memory directly to disk — what's in the struct goes in, what's on disk comes back out. Same layout, no conversion.

fwrite(pointer, size_of_one_element, count, file) is the workhorse. It returns the number of elements successfully written — if that's less than count, something went wrong and you need to check ferror(). fread mirrors it exactly: same four arguments, returns how many elements it actually read.

The critical thing to understand is that binary files are not portable across different CPU architectures. A file written on a little-endian x86 machine will have its integer bytes in reverse order compared to what a big-endian SPARC machine expects. For embedded systems or single-platform tools this doesn't matter. For cross-platform data exchange, use text or a defined binary format like protobuf. Know this tradeoff before you choose binary.

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

#define RECORDS_FILE "employees.dat"
#define MAX_NAME_LEN 50

// A fixed-size struct — perfect for binary I/O because the layout is predictable
typedef struct {
    int    employee_id;
    char   full_name[MAX_NAME_LEN];
    double annual_salary;
} Employee;

void save_employees(const Employee *employees, int count) {
    // 'wb' — write binary. Without the 'b', Windows may corrupt data
    // by translating '\n' bytes in your struct to '\r\n'.
    FILE *data_file = fopen(RECORDS_FILE, "wb");
    if (data_file == NULL) {
        perror("ERROR: Cannot open employees.dat for writing");
        exit(EXIT_FAILURE);
    }

    // fwrite returns the number of items written.
    // If it doesn't match 'count', the disk might be full.
    size_t items_written = fwrite(employees, sizeof(Employee), count, data_file);
    if ((int)items_written != count) {
        fprintf(stderr, "ERROR: Only wrote %zu of %d records\n", items_written, count);
        fclose(data_file);
        exit(EXIT_FAILURE);
    }

    fclose(data_file);
    printf("Saved %d employee record(s) to %s\n", count, RECORDS_FILE);
}

void load_and_print_employees(int expected_count) {
    FILE *data_file = fopen(RECORDS_FILE, "rb");  // 'rb' — read binary
    if (data_file == NULL) {
        perror("ERROR: Cannot open employees.dat for reading");
        exit(EXIT_FAILURE);
    }

    Employee record;  // reuse a single struct for each read

    printf("\n--- Employee Records ---\n");

    // Read one Employee at a time until fread returns 0 (EOF or error)
    int rank = 1;
    while (fread(&record, sizeof(Employee), 1, data_file) == 1) {
        printf("  [%d] ID: %04d  Name: %-20s  Salary: $%.2f\n",
               rank++,
               record.employee_id,
               record.full_name,
               record.annual_salary);
    }

    // Distinguish between EOF (normal) and a real read error
    if (ferror(data_file)) {
        perror("ERROR: Failed while reading employees.dat");
    }

    fclose(data_file);
}

int main(void) {
    Employee team[3] = {
        {1001, "Sarah Mitchell",  92500.00},
        {1002, "James Okafor",   87000.00},
        {1003, "Lin Wei",       105000.00}
    };

    save_employees(team, 3);
    load_and_print_employees(3);

    return 0;
}

Random Access and File Positioning — fseek, ftell and rewind

Sequential reading is fine for logs and config files, but a database that re-reads the whole file to update one record is a performance disaster. C gives you fseek() for jumping to any byte position, ftell() for finding out where you currently are, and rewind() as a shortcut for jumping back to the start.

fseek(file, offset, origin) takes three arguments. The origin can be SEEK_SET (from the start of the file), SEEK_CUR (relative to current position), or SEEK_END (relative to the end — useful for finding the file size). The offset is a signed long, so you can move forward or backward.

The real power of fseek emerges with fixed-size structs. Because every Employee record is exactly sizeof(Employee) bytes, you can jump to the nth record with fseek(file, n * sizeof(Employee), SEEK_SET). This is how simple flat-file databases work — and understanding this pattern demystifies a lot of file-based data storage you'll encounter in embedded systems and legacy codebases.

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

#define RECORDS_FILE "employees.dat"  // reuses file from previous example
#define MAX_NAME_LEN 50

typedef struct {
    int    employee_id;
    char   full_name[MAX_NAME_LEN];
    double annual_salary;
} Employee;

// Returns file size in bytes using fseek/ftell — a classic C idiom
long get_file_size(FILE *file) {
    fseek(file, 0, SEEK_END);    // jump to the very end
    long size = ftell(file);     // ftell returns current byte position
    rewind(file);                // rewind back to the start for subsequent reads
    return size;
}

// Update a single record by index without touching other records
void update_salary(int record_index, double new_salary) {
    // 'r+b' = read-write binary (file must already exist)
    FILE *data_file = fopen(RECORDS_FILE, "r+b");
    if (data_file == NULL) {
        perror("ERROR: Cannot open employees.dat for update");
        exit(EXIT_FAILURE);
    }

    long file_size    = get_file_size(data_file);
    int  total_records = (int)(file_size / sizeof(Employee));

    printf("File size: %ld bytes | Records: %d\n", file_size, total_records);

    if (record_index < 0 || record_index >= total_records) {
        fprintf(stderr, "ERROR: Record index %d out of range (0-%d)\n",
                record_index, total_records - 1);
        fclose(data_file);
        exit(EXIT_FAILURE);
    }

    // Jump directly to the target record — no need to read what's before it
    long byte_offset = (long)record_index * sizeof(Employee);
    fseek(data_file, byte_offset, SEEK_SET);

    // Read the current record first so we can update just the salary field
    Employee target_record;
    if (fread(&target_record, sizeof(Employee), 1, data_file) != 1) {
        perror("ERROR: Failed to read target record");
        fclose(data_file);
        exit(EXIT_FAILURE);
    }

    printf("Updating %s: $%.2f -> $%.2f\n",
           target_record.full_name,
           target_record.annual_salary,
           new_salary);

    target_record.annual_salary = new_salary;

    // Seek back to the same position — fread advanced the pointer past the record
    fseek(data_file, byte_offset, SEEK_SET);
    fwrite(&target_record, sizeof(Employee), 1, data_file);

    fclose(data_file);
    printf("Update complete.\n");
}

int main(void) {
    // Update the salary of the second employee (index 1 = James Okafor)
    update_salary(1, 95000.00);
    return 0;
}

Error Handling and Safe File I/O Patterns for Production Code

Production file I/O isn't just about reading and writing — it's about handling failures gracefully. fread and fwrite return the number of items actually transferred, which may be less than the count you asked for. You must check these returns and then call ferror() to distinguish between an end-of-file condition and a genuine I/O error. feof() tests for end-of-file but is only valid after a failed read — don't use it to predict future reads.

Buffering is another hidden concern. The C runtime buffers output internally and only flushes when the buffer fills or fclose is called. setvbuf() lets you control the buffer size or disable buffering entirely, which is critical for writing logs in crash-prone environments. For production wrappers, use a helper function that combines fopen, error checking, and setvbuf into a single call — this reduces the surface area for mistakes.

Finally, remember that the file system is a shared resource. File locks (via flock or fcntl) become necessary when multiple processes write to the same file. C's standard I/O library doesn't provide locking, so you must use OS-specific calls or external coordination.

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

// Production-safe fopen with buffer control and explicit error reporting
// Returns NULL on failure after printing a meaningful error message.
// If setbuf_size > 0, uses a custom buffer; if 0, unbuffered.
FILE *io_thecodeforge_file_open(const char *path, const char *mode, size_t setbuf_size) {
    FILE *fp = fopen(path, mode);
    if (fp == NULL) {
        fprintf(stderr, "[io_thecodeforge] ERROR: fopen(\"%s\", \"%s\") failed: %s\n",
                path, mode, strerror(errno));
        return NULL;
    }

    if (setbuf_size > 0) {
        char *buf = (char *)malloc(setbuf_size);
        if (buf == NULL) {
            // setvbuf with NULL buffer is allowed — just use default
            fprintf(stderr, "[io_thecodeforge] WARNING: malloc(%zu) failed, using default buffer\n", setbuf_size);
        } else {
            if (setvbuf(fp, buf, _IOFBF, setbuf_size) != 0) {
                fprintf(stderr, "[io_thecodeforge] WARNING: setvbuf failed, using default buffer\n");
                free(buf);
            }
        }
    } else if (setbuf_size == 0) {
        setvbuf(fp, NULL, _IONBF, 0);  // unbuffered
    }

    return fp;
}

// Safely write exactly 'count' items of 'size' bytes, retrying on short writes
int io_thecodeforge_file_write(FILE *fp, const void *data, size_t size, size_t count) {
    size_t total_written = 0;
    const unsigned char *ptr = (const unsigned char *)data;
    size_t total_bytes = size * count;

    while (total_written < total_bytes) {
        size_t written = fwrite(ptr + total_written, 1, total_bytes - total_written, fp);
        if (written == 0) {
            if (ferror(fp)) {
                fprintf(stderr, "[io_thecodeforge] ERROR: fwrite failed: %s\n", strerror(errno));
                return -1;
            }
            // Shouldn't happen with blocking I/O, but guard against infinite loop
            break;
        }
        total_written += written;
    }

    return (total_written == total_bytes) ? 0 : -1;
}

// Usage example
int main(void) {
    FILE *log = io_thecodeforge_file_open("production.log", "a", 8192);
    if (log == NULL) {
        exit(EXIT_FAILURE);
    }

    const char *msg = "Service started successfully\n";
    if (io_thecodeforge_file_write(log, msg, 1, strlen(msg)) != 0) {
        fprintf(stderr, "Failed to write startup message\n");
    }

    fclose(log);
    return 0;
}

File Opening Modes — The Silent Data Killer Is ios::trunc

Every file open call carries a mode. No mode means defaults. And defaults will destroy your data without warning.

When you open an ofstream without specifying a mode, C++ applies ios::out | ios::trunc by default. That trunc flag erases the file's existing content the moment the stream constructs. One misconfigured constructor, and your customer's configuration file is gone.

ios::app is your friend when you need to append. ios::ate positions the cursor at the end but still lets you seek backward. ios::binary turns off newline translations that corrupt binary data on Windows.

Always be explicit. Write std::ofstream logfile("transactions.log", std::ios::app) and never rely on implicit behavior. Mode flags compose with bitwise OR — that's not a coincidence, it's a design choice that gives you fine-grained control. Use it.

// io.thecodeforge — c-cpp tutorial

#include <fstream>
#include <iostream>

int main() {
    // Explicit append mode — safe for logs
    std::ofstream log("transactions.log", std::ios::app);
    if (!log) {
        std::cerr << "Failed to open log file for appending\n";
        return 1;
    }
    log << "Transaction committed at " << 1712345678 << "\n";
    log.close();

    // Binary read mode — no implicit truncation
    std::ifstream config("settings.bin", std::ios::in | std::ios::binary);
    if (!config) {
        std::cerr << "Config file not found — using defaults\n";
        return 1;
    }
    // ... read binary data
    config.close();
    return 0;
}

File Open Failure — Checking Is Cheap, Silently Corrupting Is Not

A file open failure is not an exception. It's a silent state change in the stream object. If you don't check, you'll read garbage, write to nowhere, and wonder why your report is empty.

The is_open() method or the boolean conversion operator on the stream will tell you the truth. Use one of them. Every time. Before reading or writing a single byte.

Common failure causes: file doesn't exist for ios::in, permissions insufficient for write, path is a directory, or the disk is full. These aren't edge cases — they happen in production daily.

Pattern: open, check, bail or handle. Never assume. If opening a config file fails, fall back to defaults, log the error, and continue. If opening a database file fails, stop and scream. The response depends on criticality, but the check is mandatory.

// io.thecodeforge — c-cpp tutorial

#include <fstream>
#include <iostream>

int main() {
    std::ifstream config("config.ini");
    if (!config.is_open()) {
        // Fallback: use hardcoded defaults
        std::cerr << "config.ini not found, using defaults\n";
        int retries = 3;
        std::cout << "Retries: " << retries << "\n";
        return 0;
    }
    // Read config
    std::string line;
    while (std::getline(config, line)) {
        std::cout << line << "\n";
    }
    config.close();
    return 0;
}

Asynchronous I/O with io_uring on Linux

Asynchronous I/O (AIO) allows your program to perform file operations without blocking the calling thread. On Linux, io_uring is a modern, high-performance interface for asynchronous I/O that reduces system call overhead and enables efficient submission and completion of I/O requests. Unlike traditional blocking I/O or even POSIX AIO, io_uring uses shared ring buffers between user space and kernel, minimizing context switches.

To use io_uring, you need the liburing library. Here's a simple example that reads from a file asynchronously:

```c #include #include #include #include #include

int main() { struct io_uring ring; io_uring_queue_init(32, &ring, 0);

int fd = open("example.txt", O_RDONLY); if (fd < 0) { perror("open"); exit(1); }

char buf[4096]; struct io_uring_sqe *sqe = io_uring_get_sqe(&ring); io_uring_prep_read(sqe, fd, buf, sizeof(buf), 0); io_uring_submit(&ring);

struct io_uring_cqe cqe; io_uring_wait_cqe(&ring, &cqe); if (cqe->res < 0) { fprintf(stderr, "Async read failed: %s ", strerror(-cqe->res)); } else { printf("Read %d bytes: %.s ", cqe->res, cqe->res, buf); } io_uring_cqe_seen(&ring, cqe);

close(fd); io_uring_queue_exit(&ring); return 0; } ```

This code initializes an io_uring instance, prepares a read operation, submits it, and waits for completion. The result is stored in the completion queue entry. Error handling is crucial: check cqe->res for negative values indicating errors.

io_uring supports many operations: read, write, open, close, fsync, and more. It's ideal for high-throughput servers, databases, and any application that needs to overlap I/O with computation. However, it's Linux-specific and requires a recent kernel (5.1+).

#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>
#include <unistd.h>
#include <liburing.h>

int main() {
    struct io_uring ring;
    io_uring_queue_init(32, &ring, 0);

    int fd = open("example.txt", O_RDONLY);
    if (fd < 0) { perror("open"); exit(1); }

    char buf[4096];
    struct io_uring_sqe *sqe = io_uring_get_sqe(&ring);
    io_uring_prep_read(sqe, fd, buf, sizeof(buf), 0);
    io_uring_submit(&ring);

    struct io_uring_cqe *cqe;
    io_uring_wait_cqe(&ring, &cqe);
    if (cqe->res < 0) {
        fprintf(stderr, "Async read failed: %s\n", strerror(-cqe->res));
    } else {
        printf("Read %d bytes: %.*s\n", cqe->res, cqe->res, buf);
    }
    io_uring_cqe_seen(&ring, cqe);

    close(fd);
    io_uring_queue_exit(&ring);
    return 0;
}

Memory-Mapped Files with mmap

Memory-mapped files allow you to map a file's contents directly into the process's address space, enabling file I/O via memory operations. This can be more efficient than traditional read/write for large files because it avoids intermediate buffering and system call overhead. The mmap function in POSIX systems creates a mapping.

Here's an example that maps a file and modifies it in place:

```c #include #include #include #include #include #include

int main() { int fd = open("data.bin", O_RDWR); if (fd < 0) { perror("open"); exit(1); }

struct stat sb; if (fstat(fd, &sb) == -1) { perror("fstat"); exit(1); } size_t length = sb.st_size;

char *map = mmap(NULL, length, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); if (map == MAP_FAILED) { perror("mmap"); exit(1); }

// Modify the first byte map[0] = 'A';

// Ensure changes are written back msync(map, length, MS_SYNC);

munmap(map, length); close(fd); return 0; } ```

Memory-mapped files are excellent for random access, large files, and sharing data between processes. However, they have limitations: file size is limited by address space, and mapping very large files may cause page faults. Also, mmap is not suitable for files that grow dynamically (use ftruncate to extend).

Error handling: always check return values of mmap, msync, and munmap. Use MAP_FAILED to detect mapping failure.

#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>
#include <unistd.h>
#include <sys/mman.h>
#include <sys/stat.h>

int main() {
    int fd = open("data.bin", O_RDWR);
    if (fd < 0) { perror("open"); exit(1); }

    struct stat sb;
    if (fstat(fd, &sb) == -1) { perror("fstat"); exit(1); }
    size_t length = sb.st_size;

    char *map = mmap(NULL, length, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
    if (map == MAP_FAILED) { perror("mmap"); exit(1); }

    // Modify the first byte
    map[0] = 'A';

    // Ensure changes are written back
    msync(map, length, MS_SYNC);

    munmap(map, length);
    close(fd);
    return 0;
}

File System Operations with

The header provides functions for directory traversal and file system operations in POSIX systems. It allows you to list directory contents, get file information, and navigate the file system tree. This is essential for building tools like file managers, backup utilities, or any application that needs to scan directories.

Here's an example that lists all entries in a directory:

```c #include #include #include #include

int main() { DIR *dir = opendir("."); if (dir == NULL) { perror("opendir"); exit(1); }

struct dirent *entry; while ((entry = readdir(dir)) != NULL) { printf("%s ", entry->d_name); }

closedir(dir); return 0; } ```

To get file metadata like size and permissions, use stat or lstat:

``c struct stat file_stat; if (stat(entry->d_name, &file_stat) == -1) { perror("stat"); } else { printf("Size: %ld bytes ", file_stat.st_size); } ``

Error handling: always check opendir for NULL, and readdir returns NULL on end or error (use errno to distinguish).

This API is thread-safe per directory stream, but not reentrant for readdir (use readdir_r for reentrancy).

For recursive directory traversal, implement a function that calls opendir on subdirectories. Be careful with symbolic links to avoid infinite loops.

#include <stdio.h>
#include <stdlib.h>
#include <dirent.h>
#include <sys/stat.h>

int main() {
    DIR *dir = opendir(".");
    if (dir == NULL) { perror("opendir"); exit(1); }

    struct dirent *entry;
    while ((entry = readdir(dir)) != NULL) {
        printf("%s\n", entry->d_name);
    }

    closedir(dir);
    return 0;
}