C Arrays — One <= Corrupted Memory for 6 Weeks

Every real program deals with collections of data. A weather app tracks 30 days of temperatures. A game tracks the scores of 8 players. A bank tracks thousands of account balances. If C didn't give us a way to store multiple values under a single name, you'd have to write temperature_day1, temperature_day2, temperature_day3... all the way to temperature_day30. That is not programming — that's madness.

Arrays solve this exact problem. They let you group multiple values of the same type under one variable name and access any individual value instantly using its position number. Instead of 30 separate variables, you get one array with 30 slots. Instead of writing 30 lines to print each temperature, you write one loop. That is the power arrays hand you — and it's the foundation of almost every data structure you'll ever learn.

By the end you'll know how to declare and initialize an array in C, read from it and write to it using indexes, loop through every element with a for loop, understand how arrays sit in memory, and avoid the two bugs that trip up almost every beginner on their first week.

What C Arrays Actually Do — and Why They Corrupt

A C array is a contiguous block of memory holding elements of the same type, accessed via pointer arithmetic. No bounds checking, no length stored at runtime — just a base address and an index offset. This zero-overhead design gives O(1) access but shifts all safety responsibility to the programmer.

In practice, an array decays to a pointer when passed to a function, losing size information. The compiler trusts you to stay within bounds — it will not warn you when you write past the end. A buffer overflow silently corrupts adjacent stack or heap memory, often manifesting as a crash weeks later in unrelated code.

Use C arrays when you need maximum performance and memory control — embedded systems, kernel code, or real-time audio. Avoid them in application-level code where safety matters more than a few CPU cycles. Every production use must be paired with explicit size tracking and static analysis.

Declaring and Initializing Your First C Array

Declaring an array in C follows a simple pattern: you give the data type, a name, and the number of slots you need in square brackets. That's it.

The syntax looks like this: int scores[5]; — this tells C to reserve 5 consecutive slots in memory, each big enough to hold one int, and label the whole row 'scores'. Nothing is stored in them yet — they hold garbage values until you assign something.

You can also declare and fill the array at the same time using an initializer list — curly braces with values separated by commas. When you do this, C lets you leave out the size entirely and figures it out for you by counting the values you provided.

One thing to burn into memory right now: C arrays are zero-indexed. The first element lives at index 0, the second at index 1, and so on. An array of size 5 has valid indexes 0, 1, 2, 3, and 4. Index 5 does not exist. Accessing it is the single most common bug in C programming, and we'll come back to it in the gotchas section.

Let's declare an array of 5 student test scores, initialize it with real values, and print each one.

#include <stdio.h>

int main() {
    // Declare an integer array that holds 5 test scores.
    // The number in brackets is the SIZE — total number of slots.
    int scores[5] = {88, 92, 75, 100, 63};

    // Access individual elements using their INDEX (position number).
    // Indexes start at 0, so the first score is scores[0], not scores[1].
    printf("First student score:  %d\n", scores[0]);  // prints 88
    printf("Second student score: %d\n", scores[1]);  // prints 92
    printf("Last student score:   %d\n", scores[4]);  // prints 63 — index 4, not 5!

    // You can also change a value after declaration by assigning to a specific index.
    scores[2] = 80;  // Student 3 got a re-grade — update index 2 from 75 to 80
    printf("Updated third score:  %d\n", scores[2]);  // prints 80

    return 0;
}

Looping Through an Array — The Real Power Unlocked

Accessing elements one by one with hardcoded indexes only works when your array is tiny and you already know every position you need. The real strength of arrays shows up the moment you combine them with a loop.

A for loop and an array are a natural pair. The loop counter acts as the index — it starts at 0, goes up by 1 each iteration, and stops before it reaches the array's length. This pattern is so standard in C that you'll write it thousands of times in your career.

The critical ingredient here is knowing the array's length. In C, arrays don't carry their own size around — unlike some other languages. The standard trick is to calculate the size at the point where the array is declared using the sizeof trick: sizeof(array) / sizeof(array[0]). This divides the total bytes the array occupies by the bytes one element occupies, giving you the element count. This only works in the same scope where the array was declared — we'll cover why in the gotchas.

Let's build a real example: store seven daily temperatures for a week, print them all, and calculate the average — something a weather app genuinely does.

#include <stdio.h>

int main() {
    // Seven daily temperatures in Celsius for one week.
    // Using an initializer list — C counts the values and sets the size to 7.
    float daily_temps[] = {18.5, 21.0, 19.3, 23.8, 22.1, 17.6, 20.4};

    // sizeof(daily_temps) gives total bytes the whole array uses.
    // sizeof(daily_temps[0]) gives bytes for ONE float element.
    // Dividing them gives us the number of elements — 7 in this case.
    int num_days = sizeof(daily_temps) / sizeof(daily_temps[0]);

    float total = 0.0;  // Running total so we can calculate the average

    printf("Daily temperatures this week:\n");
    printf("-----------------------------\n");

    // The loop counter 'day' doubles as the array index.
    // Condition is day < num_days (NOT <=) to stay within valid indexes.
    for (int day = 0; day < num_days; day++) {
        printf("Day %d: %.1f°C\n", day + 1, daily_temps[day]);
        // day+1 in the print just makes it human-readable (Day 1, not Day 0)

        total += daily_temps[day];  // Add each temperature to the running total
    }

    float average = total / num_days;  // Divide total by number of days
    printf("-----------------------------\n");
    printf("Weekly average: %.2f°C\n", average);

    return 0;
}

How Arrays Live in Memory — Why This Changes Everything

This section is where things get genuinely interesting — and where C separates itself from beginner-friendly languages. Understanding this will make you a better C programmer immediately.

When you declare int scores[5], C goes to RAM and finds 5 consecutive (side-by-side) memory addresses and reserves them all for you. On most systems, an int is 4 bytes, so your array occupies 20 bytes in a row. Think of it like booking 5 consecutive seats on a train — not 5 seats scattered randomly, but 5 in a row.

This matters because of how fast array access is. When you write scores[3], C doesn't search for element 3. It calculates the exact memory address mathematically: start_address + (3 × size_of_one_element). That's a single calculation — instant access regardless of whether you're accessing element 0 or element 499. This is called O(1) access time and it's why arrays are so fundamental.

The array name itself — scores, without brackets — is actually the memory address of the very first element. This is the bridge between arrays and pointers, which you'll explore later. For now, just know that when you pass an array to a function, you're passing this starting address, not a copy of all the data. That's why sizeof won't give you the element count inside a function that received the array as a parameter.

#include <stdio.h>

int main() {
    // Declare a simple integer array with 5 values
    int scores[5] = {88, 92, 75, 100, 63};

    printf("Exploring how scores[] sits in memory:\n");
    printf("---------------------------------------\n");

    // %p is the format specifier for printing a memory address (pointer)
    printf("Address of the entire array (scores):     %p\n", (void*)scores);
    printf("Address of first element (scores[0]):    %p\n", (void*)&scores[0]);
    // These two lines print THE SAME address — the array name IS the first element's address

    printf("\nElement-by-element address breakdown:\n");
    for (int i = 0; i < 5; i++) {
        // &scores[i] gives the memory address of element at index i
        // Notice each address is exactly 4 bytes higher than the previous one
        printf("  scores[%d] = %3d  stored at address: %p\n",
               i, scores[i], (void*)&scores[i]);
    }

    // sizeof the full array vs sizeof one element
    printf("\nTotal bytes used by scores[]: %zu\n", sizeof(scores));
    printf("Bytes per element (one int):  %zu\n", sizeof(scores[0]));
    printf("Number of elements:           %zu\n", sizeof(scores) / sizeof(scores[0]));

    return 0;
}

Accessing Array Elements — The Most Dangerous Thing You'll Do Today

You access an array element with the subscript operator []. packets[0] gets the first element. packets[4] gets the fifth. That's the how. Here's the why it matters: C does zero bounds checking. Ask for packets[100] on a 5-element array, and the compiler happily reads memory that belongs to something else — another variable, a function pointer, another process's data. This isn't an exception. It's not undefined behavior you'll catch during testing. It's a landmine you step on in production at 3 AM.

The fix is discipline. Always validate your index against the array size before access. Use size_t for indices — it's unsigned and matches what sizeof returns. Never trust user input, network data, or computed offsets without an explicit bounds check. If you need safety, wrap the access in a function that aborts on out-of-range. Your future self will thank you when the segfault doesn't happen.

// io.thecodeforge — c-cpp tutorial

#include <iostream>
#include <cstddef>

int main() {
    int packet_buffer[5] = {64, 128, 256, 512, 1024};
    size_t index = 3;

    // Bounds check before access
    if (index < sizeof(packet_buffer) / sizeof(packet_buffer[0])) {
        std::cout << "Packet size at index " << index << ": " << packet_buffer[index] << " bytes" << std::endl;
    } else {
        std::cerr << "ERROR: Index " << index << " out of bounds" << std::endl;
    }

    return 0;
}

Updating Array Elements — It's Just a Memory Write

Updating an array element is a single assignment: sensor_readings[2] = 42;. That's it. No function call. No copy. Just a direct write to the memory address base_address + index * element_size. That speed is why C arrays are everywhere in embedded systems, game engines, and real-time audio — they're the rawest, fastest way to mutate a sequence of data.

But that speed has a sting. Because you're writing directly to memory, there's no protection against data races in multithreaded code. Two threads updating adjacent elements can cause cache line thrashing, killing performance. And nothing stops you from overwriting the wrong index, corrupting adjacent data. The rule: keep array updates in a single thread or use atomic operations. If you need thread-safe mutations, wrap the array in a mutex or switch to std::vector with proper synchronization. But for single-threaded hot paths, raw assignment is unbeatable.

// io.thecodeforge — c-cpp tutorial

#include <iostream>

int main() {
    int sensor_readings[3] = {10, 20, 30};

    // Update the middle sensor value
    sensor_readings[1] = 25;

    // Print all readings
    for (size_t i = 0; i < sizeof(sensor_readings) / sizeof(sensor_readings[0]); ++i) {
        std::cout << "Sensor " << i << ": " << sensor_readings[i] << std::endl;
    }

    return 0;
}

C++ Array With Empty Members — The Uninitialized Landmine

You will see code where someone declares an array, slaps initializers on the first few elements, and walks away. They assume the rest are zero. They are correct — in C++. Partial initialization zero-fills the remaining members. That is a feature, not a bug. But it's also a trap.

The moment you rely on that default zero, you tie your logic to a specific initialization pattern. Change the initializer list and your zeros vanish. Worse: if you skip initialization entirely, those array slots hold whatever garbage was on the stack. You get undefined behavior. No warning. Just corruption three calls later.

Production takeaway: never assume array members are initialized unless you explicitly zero them. Use = {0} or std::fill to make intent obvious. Empty members are only safe when they are intentionally empty. Otherwise, you are debugging a ghost.

// io.thecodeforge — c-cpp tutorial

#include <iostream>

int main() {
    int partial[5] = {1, 2};         // members 2,3,4 are zero-initialized
    int garbage[5];                   // stack garbage, do not touch

    std::cout << "partial[2]: " << partial[2] << "\n";
    std::cout << "garbage[2]: " << garbage[2] << "\n"; // undefined behavior

    // Production: always zero init
    int safe[5] = {};                 // all zeros, guaranteed
    std::cout << "safe[0]: " << safe[0] << "\n";
    return 0;
}

C++ Arrays Are Not Complete Types by Default — The Compiler Knows

When you write int nums[] = {10, 20, 30};, the compiler counts the elements for you. That is convenient. But it also means the array size is deduced from the initializer — and you cannot change it later. The type of nums becomes int[3], not "some array of unknown length". This matters at compile time.

If you declare int nums[]; without an initializer, the compiler rejects it. Incomplete arrays have no size and no storage. You cannot pass them to functions without a size parameter. The moment you let the compiler deduce the size, you are locked into that exact length. There is no resizing, no dynamic growth.

Production advice: for fixed-size data, let the compiler count. For arrays that grow, use std::vector. Don't fight the type system. An array with empty members — size unknown — is a declaration with no storage. The compiler will laugh at you.

// io.thecodeforge — c-cpp tutorial

#include <iostream>

int main() {
    int known[] = {10, 20, 30};          // size = 3, deduced
    // int unknown[];                     // ERROR: incomplete type

    std::cout << "size: " << sizeof(known)/sizeof(known[0]) << "\n";

    // Array decays to pointer when passed
    auto ptr = known;                     // ptr is int*, size info lost
    std::cout << "ptr[1]: " << ptr[1] << "\n";
    return 0;
}

C23: Array Parameter with static Keyword

The C23 standard introduced a new way to specify array parameters using the static keyword, which enables compilers to perform bounds checking and optimization. When you declare a function parameter as int arr[static 5], you are telling the compiler that the array argument must have at least 5 elements. This is a contract between the caller and the callee: the caller guarantees that the array is at least that size, and the compiler can use this information for optimizations like loop unrolling or vectorization. If the caller passes a smaller array, the behavior is undefined. This feature is particularly useful for functions that expect a minimum array size, as it catches potential buffer overflows at compile time. For example, a function that sums the first 5 elements of an array can declare the parameter with static 5, and the compiler can warn if the argument is too small. Note that this is a C23 feature and may not be supported by all compilers yet; GCC and Clang have experimental support. It does not change the actual type of the parameter (arrays still decay to pointers), but it adds a semantic constraint that the compiler can enforce.

#include <stdio.h>

// C23: array parameter with static keyword
int sum_first_five(int arr[static 5]) {
    int sum = 0;
    for (int i = 0; i < 5; i++) {
        sum += arr[i];
    }
    return sum;
}

int main() {
    int valid[5] = {1, 2, 3, 4, 5};
    int invalid[3] = {1, 2, 3};
    
    printf("Sum of valid: %d\n", sum_first_five(valid));
    // Undefined behavior: invalid has only 3 elements
    // printf("Sum of invalid: %d\n", sum_first_five(invalid));
    return 0;
}

Variable-Length Arrays: C99 Feature and Compiler Support

Variable-length arrays (VLAs) are a feature introduced in C99 that allows arrays whose size is determined at runtime. For example, int n; scanf("%d", &n); int arr[n]; creates an array of size n on the stack. VLAs are useful for avoiding dynamic memory allocation when the size is known only at runtime but is not too large. However, VLAs have several drawbacks: they can cause stack overflow if the size is large, they are not supported in C++ (though some compilers allow them as extensions), and they were made optional in C11. Many compilers support VLAs, but Microsoft's MSVC does not. In embedded systems, VLAs are often discouraged because stack sizes are limited. VLAs can also be used in function parameters: void func(int n, int arr[n]) allows the array size to be passed separately. This can improve readability and enable bounds checking with tools like -fsanitize=bounds. Despite their convenience, VLAs are controversial; the Linux kernel, for instance, bans them. For production code, consider using dynamic allocation or fixed-size arrays unless you are certain the size is small and stack space is ample.

#include <stdio.h>

void print_array(int n, int arr[n]) {
    for (int i = 0; i < n; i++) {
        printf("%d ", arr[i]);
    }
    printf("\n");
}

int main() {
    int n;
    printf("Enter array size: ");
    scanf("%d", &n);
    
    // VLA on stack
    int arr[n];
    for (int i = 0; i < n; i++) {
        arr[i] = i * 2;
    }
    
    print_array(n, arr);
    return 0;
}

Multidimensional Arrays as Flat Buffers

Multidimensional arrays in C are stored in row-major order, meaning all rows are laid out contiguously in memory. This allows you to treat a 2D array as a flat 1D array, which can be more efficient for certain operations. For example, int matrix[3][4] can be accessed as int flat = (int)matrix; and then indexed as flat[i 4 + j]. This flat buffer approach is useful when you need to pass the array to functions that expect a contiguous block of memory, or when performing operations like memset or memcpy. It also avoids the overhead of pointer-to-pointer structures used in dynamic 2D arrays. However, be careful with the indexing: the formula is row num_cols + col. This technique is common in graphics programming, scientific computing, and embedded systems where memory layout matters. One pitfall is that the compiler may not optimize the flat indexing as well as the native 2D indexing, so profile if performance is critical. Also, when using flat buffers, you lose the type safety of multidimensional array types, so ensure you pass the dimensions correctly.

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

void print_flat(int* arr, int rows, int cols) {
    for (int i = 0; i < rows; i++) {
        for (int j = 0; j < cols; j++) {
            printf("%d ", arr[i * cols + j]);
        }
        printf("\n");
    }
}

int main() {
    int matrix[3][4] = {
        {1, 2, 3, 4},
        {5, 6, 7, 8},
        {9, 10, 11, 12}
    };
    
    // Treat as flat buffer
    int* flat = (int*)matrix;
    
    // Use memset on entire array
    memset(flat, 0, sizeof(matrix));
    
    // Set some values using flat indexing
    flat[1 * 4 + 2] = 42;  // row 1, col 2
    
    print_flat(flat, 3, 4);
    return 0;
}