conceptual problem

[I_m_rude]

int main()
{
    extern int i;

    i=20;

    printf("%d\n",i);
}

hi..
actually this is asked to me today. In this no i is defined anywhere. only declaration is given in main(). then i was asked when the error will come ?
like is it segmentation fault, linking error, complilation error or what ? And why ? thanks. I was damn confused while thinking for this. thanks.

[deceptikon]

Undefined objects or functions will be reported at link time. You might also get a warning during compilation, but link time is the hard stop point.

[I_m_rude]

but when i don't declare a variable then compilation error is there. then why is this case linking one? (I have guessed linking at that time ;) hehe)

[deceptikon]

but when i don't declare a variable then compilation error is there.

If you use an undeclared variable, the compiler will complain because it has no idea what you're referring to. If you declare a variable but don't define it, the linker complains because what you're referring to doesn't exist.

[rubberman]

The variable i needs to be instantiated outside of main, either in the same file, or in another one that is subsequently linked to create the executable. Try this:

#include <stdio.h>

int i = 0;

int main(void)
{
    extern int i;
    i=20;
    printf("%d\n",i);
    return 0;
}

In any case, your code should compile, but it will not link as it stands. Actually, the compiler should complain and may error out since you forgot the return value.

[I_m_rude]

that means the thing which i am doing outside main is definition means allocating memory ? Right ? And what i am doing inside main in this case is declaring. right ? And when i have declared a variable but didn't define it, then linker will give error, why not compiler ? isn't compiler don't know that this variable is not defined yet ? thanks.

[WaltP]

No, the compiler doesn't know. You told the compiler that the variable was defined somewhere else. That's all the compiler knows. It trusts you.

Its when you try to link the declaration with a definition that the linker finds your error.

[I_m_rude]

ohh.. ok ... I got it now.. thanks to waltP sir. ;)

[deceptikon]

And when i have declared a variable but didn't define it, then linker will give error, why not compiler ? isn't compiler don't know that this variable is not defined yet ?

As Walt said, the compiler doesn't know. It doesn't know because all it's compiling is a single translation unit, but the project could contain many files and many translation units, all in various stages of building. Here are two examples (of many) that make multi-file introspection a non-trivial and inefficient task:

1. Simple Case ($ cc main.c impl.c): main.c declares foo, and foo is defined in impl.c. While compiling main.c the compiler would need to search through all other source and header files not included in main.c for the definition of foo before it could accurately produce a diagnostic message.

2. Hard Case ($ cc main.c impl.o): main.c declares foo, and foo is defined in impl.c. But impl.c has already been compiled into impl.o, and the compiler doesn't have access to impl.c. Now it has to do part of the linker's job and search through impl.o for exported definitions of foo before it can correctly report undefined objects.

[I_m_rude]

james sir, But can you tell me one thing that why the compiler need to search those header files which are not included in the main.c ? Even , why will it do that ?

secondly, Can you explain your hard case again ? I didn't get that. thanks in advance.

[deceptikon]

why the compiler need to search those header files which are not included in the main.c ?

Because there might be a definition of the variable or function in one of those other files. The headers that are included are already part of the translation unit, so the compiler can see them. Note that a translation unit is basically what the compiler works with after the preprocessor runs.

Can you explain your hard case again ?

I'm guessing you haven't worked with a command line compiler before. ;) Modern IDEs make multi-file projects easier to work with and build, but it can hide the nitty gritty aspects of building such as separate compilation.

C supports separate compilation in that you can compile some source files into an object file. That object file can then be used by the linker at any time without requiring you to recompile the original source files (unless they change).

The compiler and linker often run in the same invokation of a "compiler" program like gcc, or tcc (Turbo C's compiler), or bcc32 (Borland C++'s compiler), or cl (Microsoft's compiler). So you can pass in both source files for compilation and object files for linking all in the same command line (ie. gcc main.c impl.o).

And therein lies the problem, because the compiler can't see what's in those object files even though they might contain exactly the definitions that would suppress an undefined object or function error.