Thread: Help with the size of the object files and extended source file

1.c

Code:

#include<stdio.h>
main()
{
}

commands used

$ cc -E 1.c -o 1.i <--to create extd source file
$ cc -c 1.c <----to create object file

2.c

Code:

#include<stdio.h>
#include<string.h>
main()
{
}

commands used

$ cc -E 2.c -o 2.i
$ cc -c 2.c

When I use 'll' command (long format)

-rw-r--r-- 1 user user 29 2011-12-14 01:18 1.c
-rw-r--r-- 1 user user 17036 2011-12-14 01:16 1.i
-rw-r--r-- 1 user user 666 2011-12-14 01:17 1.o
-rw-r--r-- 1 user user 48 2011-12-14 01:22 2.c
-rw-r--r-- 1 user user 38432 2011-12-14 01:18 2.i
-rw-r--r-- 1 user user 666 2011-12-14 01:18 2.o

red=> size of file.

As you can see the size of the 1.o and 2.o are same and the size of the 1.i is much greater than that of the 1.o (object file).

Can someone enlighten me on this?
why and how the included files (header files) are removed after 'PREPROCESSING STAGE'.

Compilers are intelligent. If you have a 7,000,000 line header file but only use one definition or variable in it, it will ONLY include that one variable. Your two programs are identical in operation and don't use anything from string.h at all, so first the preprocessor will actually make one large file that contains stdio.h, string.h and your code all joined together (that's what a preprocessor does). The compiler will read through it all, realise that 99% of it is never used and only "compile" the bits that actually do something. It won't even compile functions that are never called, in most modern compilers, so you might have a 1,000,000 line function that never even makes it into the final executable.

Hence your two output binaries are not only the same size but probably absolutely identical. In the same way, changing a variable name won't change the object code at all, because variable names aren't understood by the machine and the compiler has no need to put them in there (unless you've deliberately included them by enabled debug modes, profiling, etc.). However, the compiler is *not* always smart enough to detect two pieces of similar *code* that do the same job (e.g. i=2+2 and i = 2; i+= 2 so even the most minor of changes to the "processing path" (if you like, the instructions the computer has to execute to come to your answer) can change the object code (some compilers will spot simple changes like the above, of course, but not all).

It's no different to sending a translator a pile of documents but telling them that only the main document and it's footnotes needs translation. If the main document doesn't reference anything in the 1000's of pages you've given them, they won't translate them all because you don't need them. And if the documents reference only one paragraph in a huge volume, they will probably only translate that paragraph for you.

Be thankful it works this way, or every program would probably be twice the size it is! There are tools that can do this sort of "editing" to finished binaries too - see the Unix "strip" program - and they can often chop your executables in half if you've linked in too much stuff that never actually gets used.