Fix “expected declaration at end of input” in C

Usually, a function or block is missing its closing }. Match opening and closing braces in the affected function, then recompile. An error reported at the end of the file may originate earlier. Do not add braces blindly: placement changes program behavior.

A missing-brace example

This example is intentionally incomplete:

#include <stdio.h>

int main(void)
{
    int score = 75;
    if (score >= 50) {
        puts("Pass");
    }
    return 0;
/* Missing closing brace for main. */

In the broken example, the brace after puts closes the if block. It does not also close main. GCC commonly reports expected declaration or statement at end of input here, though the exact wording and line numbers depend on the compiler and source file.

Corrected, runnable program

#include <stdio.h>

int main(void)
{
    int score = 75;
    if (score >= 50) {
        puts("Pass");
    }
    return 0;
}

Expected output:

Pass

The final closing brace now correctly closes the function. You can test the fixed version of the code in the online C compiler.

How to find the actual missing brace

1. Read the first diagnostic in the compiler output. Later messages may be consequences of the same mistake.
2. Start at the function containing the reported error and match each opening { with its intended closing }.
3. Reindent the function. A block that unexpectedly contains the rest of the file often reveals the problem.
4. Inspect the lines you most recently changed, especially loops, conditions, and nested blocks.
5. Recompile after one structural fix so you can see which errors remain.

Do not keep adding closing braces at random until the build succeeds. A brace in the wrong place can move statements into or out of a block and change the program's behavior.

If the braces look balanced

A simple character count is not always accurate. Closing braces in comments or string literals are not block delimiters. For example, puts("{"); will not open a C block.

Also check conditional compilation. An #if branch can remove a closing brace from the source the compiler sees. If the problem depends on build flags, inspect the preprocessed output locally:

gcc -E main.c -o main.i

Look in main.i for your function. Included headers can make the file long. Use the same -D macros and include paths as the failing build. The GCC documentation explains how -E stops after preprocessing.

Similar errors require different fixes

Unterminated strings, unfinished comments, missing parentheses, and unmatched preprocessing directives can also stop parsing from finishing. They often produce different diagnostics. Fix the first specific message instead of treating every end-of-file error as a missing brace.

The message expected declaration specifiers is also different.

Can a missing semicolon cause this?

A missing semicolon usually produces a diagnostic about the next token. Check earlier messages, but for this end-of-input diagnostic, first look for an unfinished block.

Why is the error on the final line?

While a block is open, the compiler can continue to expect more. It is only after the end of the input that it becomes clear the construct was never completed.

After the program builds, run inputs that exercise the affected branches. Successful compilation confirms that the syntax is accepted; testing helps confirm that the brace is in the intended place.