# main Function Variants, Unused Variables & Real-World Use Cases

So far, you’ve learned:

*   How programs receive input (`argc`, `argv`)
    
*   How to access and process arguments
    

Now we complete the picture.

This lesson answers three important questions:

> *   Why does `main` sometimes look different?
>     
> *   What do we do with unused variables?
>     
> *   Where is this actually used in real life?
>     

## 1\. Two Ways to Write `main`

You may see `main` written in two ways:

### Version 1

```c
int main(int argc, char *argv[])
```

### Version 2

```c
int main(int argc, char **argv)
```

## 2\. Are They Different?

No.

They are **exactly the same**.

### Why?

Because in C:

```text
char *argv[]  ≡  char **argv
```

Both represent:

> An array of strings (arguments)

### Which One Should You Use?

Use whichever is clearer to you.

Most beginners prefer:

```c
char *argv[]
```

because it clearly shows that `argv` is an array.

## 3\. Handling Unused Variables

Sometimes you won’t use `argc` or `argv`.

Example:

```c
int main(int argc, char *argv[])
{
    return 0;
}
```

The compiler may warn you:

```text
unused parameter 'argc'
unused parameter 'argv'
```

## 4\. How to Fix This

### Option 1: Use `(void)`

```c
(void)argc;
(void)argv;
```

### Option 2: Use Attribute

```c
int main(int argc __attribute__((unused)), char *argv[] __attribute__((unused)))
```

### Which Should You Use?

👉 For beginners:

```c
(void)argc;
(void)argv;
```

Simple and clear.

## 5\. Why This Matters

Your compiler is strict (especially with flags like `-Wall -Werror`).

Warnings can stop your program from compiling.

So you must handle unused variables properly.

## 6\. Real-World Use Cases of `argc` and `argv`

Now let’s connect everything to real programs.

## 🔹 1. File Processing

Example:

```bash
./program input.txt
```

Your program reads the file name from `argv`.

## 🔹 2. Command-Line Tools

You already use tools like:

```bash
gcc file.c -o output
```

Here:

*   `file.c`
    
*   `-o`
    
*   `output`
    

are all arguments.

## 🔹 3. Flags and Options

Example:

```bash
./program -v
```

Your program can behave differently based on input.

## 🔹 4. Simple Calculators

Example:

```bash
./program 5 10
```

Your program can process values passed from the terminal.

## 7\. Connecting to Your Project

From your project tasks , you will need to:

*   access the program name
    
*   count arguments
    
*   loop through arguments
    
*   process user input
    
*   validate inputs
    

## 8\. Thinking Like a Programmer

Before writing code, ask:

### 1\. How many arguments should I expect?

```text
argc tells you this
```

### 2\. What should happen if they are missing?

```text
handle errors properly
```

### 3\. What type of data am I receiving?

```text
all arguments are strings
```

### 4\. Do I need to convert the input?

```text
use atoi() or similar
```

## 9\. Common Beginner Mistakes

### ❌ Forgetting `argv[0]` is the program name

Students often assume:

```text
argv[0] = first argument ❌
```

Correct:

```text
argv[0] = program name
```

### ❌ Not checking `argc`

Accessing arguments blindly can crash your program.

### ❌ Ignoring compiler warnings

Warnings matter, especially with strict compilation flags.

## 10\. Practice Thinking

Try to reason through these:

1.  If you run:
    
    ```bash
    ./program start stop
    ```
    
    What is `argc`?
    
2.  What is stored in `argv[1]`?
    
3.  How would your program behave differently based on input?
    

## Key Ideas to Remember

*   `main` has two valid forms
    
*   `argc` counts arguments
    
*   `argv` stores arguments
    
*   Unused variables must be handled properly
    
*   Command-line arguments make programs dynamic
    

## Final Thoughts

This week marks an important shift.

Before, your programs were:

```c
fixed and predictable
```

Now, they become:

```text
dynamic and user-driven
```

You are no longer just writing code.

You are building programs that respond to users — just like real tools.

## What Comes Next

You now have everything you need to approach the project.

Focus on:

*   understanding input
    
*   validating arguments
    
*   structuring your program properly
    

Take your time.

This is where your programs start to feel like real software.