1. Why Understanding Error Types Matters

When you build a circuit and it doesn’t work, you use a multimeter, check voltages, and trace signals. Similarly, when a C program fails, you need to know:

• Where the problem is: during compilation, during execution, or in the formula/logic.
• What kind of error it is: syntax, missing file, wrong pointer, infinite loop, etc.
• How to systematically debug and fix it without guessing randomly.

2. Compile-Time Errors (Syntax & Semantic Errors)

Compile-time errors are reported by the compiler (e.g., GCC) when it tries to translate your .c file into machine code. If compile-time errors exist, the compiler usually does not generate an executable.

2.1 Syntax error examples

#include <stdio.h>

int main() {
    int a = 10
    printf("a = %d\n", a);
    return 0;
}

Here, the line int a = 10 is missing a semicolon. Compiler message (approx):

error: expected ';' before 'printf'

2.2 Type mismatch example

#include <stdio.h>

int main() {
    int a = 10;
    float b = 5.5f;

    printf("Sum = %d\n", a + b);   // wrong format specifier
    return 0;
}

Many compilers show a warning here:

warning: format '%d' expects argument of type 'int',
but argument 2 has type 'double'

2.3 Undeclared identifier example

#include <stdio.h>

int main() {
    total = 10;   // 'total' never declared
    printf("%d\n", total);
    return 0;
}

Compiler error:

error: 'total' undeclared (first use in this function)

3. Runtime Errors – Crashes & Abnormal Behaviour

Runtime errors happen when the program is running. The code compiles successfully, but something goes wrong while executing: divide by zero, invalid memory access, file not found, etc.

3.1 Divide-by-zero example

#include <stdio.h>

int main() {
    int energy, units;
    printf("Enter total energy and units: ");
    scanf("%d %d", &energy, &units);

    int perUnit = energy / units;   // danger if units == 0
    printf("Per unit = %d\n", perUnit);

    return 0;
}

If the user enters units = 0, the program may crash or show undefined behaviour.

3.2 Array out-of-bounds example

#include <stdio.h>

int main() {
    int a[5];
    int i;

    for (i = 0; i <= 5; i++) {  // error: should be i < 5
        a[i] = i * 10;
    }

    return 0;
}

The loop writes to a[5], which is outside the valid range (0–4). Sometimes this causes a crash (segmentation fault), sometimes it silently corrupts memory, producing strange bugs later.

3.3 Null pointer dereference example

#include <stdio.h>

int main() {
    int *ptr = NULL;
    printf("%d\n", *ptr);  // dereferencing NULL -> runtime crash
    return 0;
}

Accessing memory through a NULL pointer is a classic runtime error.

4. Logical Errors – Program Runs but Output Is Wrong

Logical errors are the most dangerous ones because:

• The program compiles successfully (no compile-time error).
• The program runs without crashing (no runtime error).
• The output is wrong – your calculation or decision logic is incorrect.

4.1 Wrong formula example – average

#include <stdio.h>

int main() {
    int a = 10, b = 20, c = 30;
    float avg;

    avg = a + b + c / 3;   // logical error in formula
    printf("Average = %.2f\n", avg);

    return 0;
}

According to C’s precedence rules, this is:

a + b + (c / 3)

instead of:

(a + b + c) / 3

4.2 Off-by-one error in loops

#include <stdio.h>

int main() {
    int i;
    for (i = 1; i <= 10; i++) {
        printf("%d ", i);
    }
    // Suppose we wanted to print only 1 to 9 – loop condition is off by one.
    return 0;
}

Off-by-one errors appear very often in loops and array indexing.

4.3 Wrong comparison operator

if (voltage = 230) {   // assignment, not comparison
    printf("Voltage is 230V\n");
}

This assigns 230 to voltage instead of comparing. The condition becomes true for all cases. The correct version is:

if (voltage == 230) {
    ...
}

5. Warnings vs Errors – Why Warnings Matter

Compilers usually distinguish between:

• Errors – program will not compile.
• Warnings – program compiles, but compiler suspects a bug.

• “Format ‘%d’ expects argument of type ‘int’, but argument 2 has type ‘float’”.
• “Control reaches end of non-void function”.
• “Variable ‘x’ is used uninitialized”.

6. How to Read Compiler Error Messages

When the compiler prints an error, it usually gives:

• File name (e.g., main.c).
• Line number (e.g., line 12).
• Column or position.
• A short description of the problem.

Example error message

main.c:12:5: error: expected ';' before 'return'

Interpretation:

• File: main.c
• Line: 12, column: 5
• Problem: the compiler was expecting a semicolon before the keyword return.

7. Debugging Tips – Step-by-Step Approach

Debugging is a process, not magic. Here are practical techniques that work in real C programs.

7.1 Use printf as a “software multimeter”

Just like you probe voltages, you can probe variable values using printf:

printf("DEBUG: i = %d, sum = %d\n", i, sum);

Insert such statements around suspicious logic to see:

• Whether loops are running the expected number of times.
• How variables change step by step.
• Where the program “jumps” into unexpected branches.

7.2 Reduce the problem – create a small test program

If a bug appears in a large project:

1. Copy the related function / logic into a small separate .c file.
2. Hard-code some test data.
3. Run only that part until the bug is understood.

7.3 Check boundaries and assumptions

• Array loops: verify start and end index. Are you going from 0 to n-1 or 1 to n?
• Division: ensure denominator is never 0.
• Pointers: make sure they are initialized before use; check for NULL.
• File handles: always check if fopen returned NULL before reading/writing.

7.4 Use a debugger (gdb / IDE debugger)

Many IDEs (Code::Blocks, VS Code with extensions, etc.) let you:

• Set breakpoints where the program will pause.
• Step through code line by line (step, next).
• Inspect variable values and call stack.

7.5 Don’t change too many things at once

When debugging:

• Change one small thing, recompile, test.
• If the bug is still there, undo or adjust and try a different change.
• Keep notes of what you tried and what happened.

8. Debugging Checklist – For Every C Program

• I read the first compiler error carefully and fix it before worrying about the rest.
• I treat warnings seriously and try to keep my program warning-free.
• I validate user input (especially for divisions and array sizes).
• I check array bounds and loop limits to avoid off-by-one errors.
• I test formulas with simple known values to catch logical errors early.
• I use printf or a debugger to trace variable values step by step.
• I avoid making many random changes at once; I debug systematically.
• I understand the difference between compile-time, runtime and logical errors.