DEV Community: Ujjawal Chaudhary

Day 9: Iteration vs. Recursion: Analyzing Performance (Factorial)

Ujjawal Chaudhary — Sat, 17 Jan 2026 17:33:01 +0000

Is Recursion better than a Loop? It depends.

Recursion is often cleaner to write and easier to read (especially for trees). But it comes at a cost: Space Complexity.

Iteration: Uses 1 Stack Frame. It just updates a variable in a loop. Space is $O(1)$.
Recursion: Uses N Stack Frames. If you calculate factorial(10000), you push 10,000 frames onto memory. Space is $O(N)$.

If you go too deep, recursion crashes (Stack Overflow). Iteration runs forever.

The Code

Here I implemented Factorial in both ways to compare the syntax.



// Day 9: The Two Paths

#include <stdio.h>

// Method 1: Recursive (The Elegant Way)
// Risks: Stack Overflow for large numbers
unsigned long long factorial_rec(int n) {
    if (n <= 1) return 1;
    return n * factorial_rec(n - 1);
}

// Method 2: Iterative (The Efficient Way)
// Benefits: Uses constant memory (No stack growth)
unsigned long long factorial_iter(int n) {
    unsigned long long res = 1;
    for (int i = 1; i <= n; i++) {
        res *= i;
    }
    return res;
}

int main() {
    int num = 5;
    printf("Recursive: %llu\n", factorial_rec(num));
    printf("Iterative: %llu\n", factorial_iter(num));
    return 0;
}

📂 View the source code on GitHub: https://github.com/Ujjawal0711/30-Days

Day 8: Visualizing the Call Stack: How Recursion Actually Works

Ujjawal Chaudhary — Thu, 15 Jan 2026 15:39:29 +0000

We've all heard the term "Stack Overflow," but today I visualized what it actually means.

When a function calls itself (Recursion), it doesn't just "loop." The computer actually pauses the current function, packages up all the variables, and pushes a new Stack Frame onto memory.

Frame 1: n = 3 (Paused)
Frame 2: n = 2 (Paused)
Frame 3: n = 1 (Running)

If you recurse too deep without stopping, you run out of Stack memory. Boom. Stack Overflow.

The Code

This program prints the memory address of the local variable n during each recursive call. You will see the addresses moving down in memory, proving that each call creates a new, distinct stack frame.



// Day 8: Visualizing Stack Frames

#include <stdio.h>

void recursive_print(int n) {
    // Base case: Stop when n hits 0
    if (n == 0) {
        printf("Base case reached. Popping stack now...\n");
        return;
    }

    // Print the address of 'n' to see the stack grow
    // Notice the addresses get smaller (Stack grows DOWN)
    printf("Frame %d | Address of n: %p\n", n, (void*)&n);

    // Recursive step: Call itself with n-1
    recursive_print(n - 1);

    printf("Returning from Frame %d\n", n);
}

int main() {
    recursive_print(3);
    return 0;
}

📂 View the source code on GitHub:https://github.com/Ujjawal0711/30-Days

Day 7: Week 1 Retrospective: Mastering C Pointers & Memory Internals

Ujjawal Chaudhary — Wed, 14 Jan 2026 07:02:52 +0000

I survived Week 1 of my Low-Level Engineering challenge. 🚀

This week wasn't just about syntax; it was about mental models. I learned that high-level languages like Python and JS hide a massive amount of complexity from us.

The Big Takeaways:

Arrays are a Lie: They are just pointers to the first element. arr[i] is just syntactic sugar for *(arr + i).
Memory has Geography: The Stack is safe but small. The Heap is massive but dangerous. You have to choose where your data lives.
Strings don't exist: They are just char arrays that hope you didn't forget the null terminator \0.

The Code

I wrote a summary program that uses a Struct to recap the week's stats.



// Day 7: Weekly Retrospective

#include <stdio.h>

struct Week1 {
    int days_coded;
    char *topics_mastered[4];
    char *biggest_struggle;
};

int main() {
    struct Week1 recap = {
        .days_coded = 7,
        .topics_mastered = {
            "Pointer Arithmetic", 
            "Stack vs Heap", 
            "Null Terminators", 
            "Structs"
        },
        .biggest_struggle = "Understanding Array Decay"
    };

    printf("Week 1 Status: COMPLETE ✅\n");
    printf("Struggle: %s\n", recap.biggest_struggle);

    return 0; // Ready for Week 2
}

📂 View the source code on GitHub:https://github.com/Ujjawal0711/30-Days

Day 6: Structs in C: Organizing Data without Classes

Ujjawal Chaudhary — Tue, 13 Jan 2026 15:45:01 +0000

In languages like Java or Python, you use Classes to bundle data together. C doesn't have Classes. It has something rawer: Structs.

A struct (Structure) is how we create custom data types.

Without structs, if I wanted to store a student's data, I'd have to manage separate variables:

char *name1
int age1
float gpa1

With structs, I can group them into a single Student type. This is the ancestor of the "Object" in Object-Oriented Programming.

The Code

Here is how we define and use a custom data type in C.



// Day 6: Grouping chaos into order

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

// Before: Messy variables scattered everywhere
// char *name1 = "Alice"; int age1 = 20;

// After: A custom Data Type
// We define a blueprint called "Student"
typedef struct {
    char name[50];
    int age;
    float gpa;
} Student;

int main() {
    // Now we treat the data as a single "Object"
    // We can initialize it just like an array
    Student s1 = {"Alice", 20, 3.8};

    // We access fields using the dot operator (.)
    printf("Name: %s\n", s1.name);
    printf("GPA:  %.2f\n", s1.gpa);

    return 0;
}


📂 View the source code on GitHub:https://github.com/Ujjawal0711/30-Days

Day 5: C Strings: The Danger of the Null Terminator (\0)

Ujjawal Chaudhary — Mon, 12 Jan 2026 21:18:02 +0000

In Python or Java, strings are objects. You don't worry about how they end.

In C, a string is just a lie. It's actually just a character array.

So how does the computer know where the string stops? It looks for a secret hidden character called the Null Terminator (\0).

If you forget space for this \0, functions like printf won't stop reading.
They will keep printing memory (garbage data, or even sensitive data) until they accidentally hit a 0 somewhere in your RAM.

This is the root cause of the famous Buffer Overflow vulnerability.

The Code

Here is the code demonstrating "Safe" vs "Unsafe" strings.



// Day 5: The most dangerous character in C

#include <stdio.h>

int main() {
    // 1. Safe String (Compiler adds \0 automatically)
    // Size is 6 bytes ('H', 'e', 'l', 'l', 'o', '\0')
    char safe[] = "Hello"; 

    // 2. Unsafe String (Manually built, NO null terminator)
    // Size is 2 bytes. 
    char unsafe[2] = {'H', 'i'}; 

    printf("Safe String: %s\n", safe);

    // DANGER: printf keeps reading memory until it finds a 0.
    // It will print "Hi" followed by random garbage from your RAM!
    printf("Unsafe String: %s\n", unsafe);

    return 0;
}

📂 View the source code on GitHub: https://github.com/Ujjawal0711/30-Days

Day 4: The Sizeof Trap: Understanding Array Decay in C

Ujjawal Chaudhary — Sun, 11 Jan 2026 17:09:07 +0000

If you pass an array to a function in C, you might be in for a rude awakening when you check its size.

This is called Array Decay.

When an array is passed to a function, it "decays" into a simple pointer to its first element. It forgets how long it is.

Inside main, sizeof(arr) tells you the total bytes of the array.
Inside a function, sizeof(arr) only tells you the size of the pointer address (usually 8 bytes on 64-bit systems).

The Code

Run this code to see the "Lie" in action.



// Day 4: Arrays vs. Pointers (The Nuance)

#include <stdio.h>

void print_size(int arr[]) {
    // WARNING: 'arr' here has decayed to a pointer!
    // It is no longer an array.
    printf("Size inside function: %zu bytes (Pointer size)\n", sizeof(arr));
}

int main() {
    int arr[] = {1, 2, 3, 4, 5};

    // 1. Size of the Array in local scope
    // Returns 20 (5 ints * 4 bytes each)
    printf("Size in main: %zu bytes\n", sizeof(arr));

    // 2. Pass it to a function
    print_size(arr);

    return 0;
}

📂 View the source code on GitHub:https://github.com/Ujjawal0711/30-Days/

With Great Power Comes Great Responsibility (and Segfaults) 🧠

Ujjawal Chaudhary — Fri, 09 Jan 2026 13:07:56 +0000

Day 3/30: Stack vs. Heap.

On the Stack, variables are cleaned up automatically when a function ends. It's safe, but limited in size.

On the Heap (using malloc), you can allocate massive amounts of memory that persist as long as you want. But there is a catch: You are the Garbage Collector.

The Rule of Thumb: For every malloc() you write, write the free() immediately.
If you forget, that memory block stays occupied until your program dies. Do this enough times in a long-running server, and you crash the system.

Today was all about learning to borrow resources and ensuring I return them.

The Code

Here is the C code for Day 3:



// Day 3: The Danger of the Heap

#include <stdio.h>
#include <stdlib.h> // Required for malloc/free

void dangerous_function() {
    // Requesting memory from the Heap
    // This lives outside the function's scope
    // 100 integers * 4 bytes = 400 bytes allocated
    int *data = (int*)malloc(100 * sizeof(int));

    // Always check if the OS actually gave you the memory
    if (data == NULL) {
        printf("Memory allocation failed!\n");
        return; 
    }

    // ... process data ...
    data[0] = 42;
    printf("Heap memory allocated. Value: %d\n", data[0]);

    // CRITICAL: If you forget this, the memory 
    // remains "occupied" forever (Memory Leak)
    free(data); 

    // Good practice: Remove the dangling pointer
    // so you don't accidentally use it again
    data = NULL;
    printf("Heap memory freed.\n");
}

Pointer Arithmetic: Traversing Memory without an Index

Ujjawal Chaudhary — Thu, 08 Jan 2026 13:27:37 +0000

Why use an Index when you can touch the Memory? 👉

Day 2/30: Pointer Arithmetic.

Most tutorials teach you to loop through arrays using i (the index). But in Systems Programming, we often manipulate the address directly.

The Magic: When you write ptr++ in C, the compiler is smart. It doesn't just add "1" to the address. It adds sizeof(int) (usually 4 bytes).

If ptr was a char, it would add 1 byte. If ptr was a struct, it would jump the size of the whole struct.

This snippet allows us to iterate through data purely by comparing memory addresses, which is more direct and cleaner in low-level drivers.

The Code

Here is the C code for Day 2:



// Day 2: Traversing Memory without an Index

void iterate_with_pointers(const int *ptr, int size) {
    // We don't need 'i' or 'array[i]'
    // We just look at the end address
    int *end = ptr + size;

    while (ptr < end) {
        // Dereference the current address to get value
        printf("Value: %d\n", *ptr);

        // Move the pointer to the next integer block
        // (Jumps 4 bytes automatically)
        ptr++; 
    }
}

Day 1: The Array Lie (Arrays vs Pointers in C)

Ujjawal Chaudhary — Wed, 07 Jan 2026 06:05:19 +0000

Today marks Day 1 of my 30-Day Coding Challenge to master C internals, Algorithms, and Database design.

Why am I doing this? In a world of AI and high-level abstractions, understanding how memory works under the hood is what separates a coder from an engineer. I want to build that foundational strength.

Today's Concept: The Array Lie; We often think of arrays as rigid lists. In C, the variable name of an array is actually just a pointer to the first element.

As shown in the snippet, numbers[1] is really just a human-readable way of writing *(numbers + 1). The computer adds the size of the data type to the base address to find the value.

Follow along for the next 29 days as I document my deep dive into system internals and optimization.

📂 View the source code on GitHub: [https://github.com/Ujjawal0711/30-Days/tree/main]