![[*]](/opt/LaTeX2html/icons.gif/cross_ref_motif.gif){kind=icon}
and exercises for more
info.)
In this chapter we begin by outlining the basic processes you need to go through in order to compile your C (or C++) programs. We then proceed to formally describe the C compilation model and also how C supports additional libraries.
The stages of developing your C program are as follows. (See
Appendix and exercises for more
info.)
Create a file containing the complete program, such as the above example. You can use any ordinary editor with which you are familiar to create the file. One such editor is textedit available on most UNIX systems.
The filename must by convention end ``.c'' (full stop, lower case c), e.g. myprog.c or progtest.c. The contents must obey C syntax. For example, they might be as in the above example, starting with the line /* Sample .... (or a blank line preceding it) and ending with the line } /* end of program */ (or a blank line following it).
There are many C compilers around. The cc being the default Sun compiler. The GNU C compiler gcc is popular and available for many platforms. PC users may also be familiar with the Borland bcc compiler.
There are also equivalent C++ compilers which are usually denoted by CC (note upper case CC. For example Sun provides CC and GNU GCC. The GNU compiler is also denoted by g++
Other (less common) C/C++ compilers exist. All the above compilers operate in essentially the
same manner and share many common command line options. Below and in
Appendix we list and give example uses many of the common compiler options.
However, the best source of each compiler is through the online manual pages of your
system: e.g. man cc.
For the sake of compactness in the basic discussions of compiler operation we will simply refer to the cc compiler -- other compilers can simply be substituted in place of cc unless otherwise stated.
To Compile your program simply invoke the command
cc. The command must
be followed by the name of the (C) program you wish to compile. A number of compiler options
can be specified also. We will not concern ourselves with many of these options yet, some
useful and often essential options are introduced below -- See Appendix or
online manual help for further details.
Thus, the basic compilation command is:
cc program.c
where program.c is the name of the file.
If there are obvious errors in your program (such as mistypings, misspelling one of the key words or omitting a semi-colon), the compiler will detect and report them.
There may, of course, still be logical errors that the compiler cannot detect. You may be telling the computer to do the wrong operations.
When the compiler has successfully digested your program, the compiled version, or executable, is left in a file called a.out or if the compiler option -o is used : the file listed after the -o.
It is more convenient to use a -o and filename in the compilation as in
cc -o program program.c
which puts the compiled program into the file program (or any file you name following the "-o" argument) instead of putting it in the file a.out .
The next stage is to actually run your executable program. To run an executable in UNIX, you simply type the name of the file containing it, in this case program (or a.out)
This executes your program, printing any results to the screen. At this stage there may be run-time errors, such as division by zero, or it may become evident that the program has produced incorrect output.
If so, you must return to edit your program source, and recompile it, and run it again.
We will briefly highlight key features of the C Compilation model (Fig. 2.1) here.
Fig. 2.1 The C Compilation Model
We will study this part of the compilation process in greater detail later (Chapter 13. However we need some basic information for some C programs.
The Preprocessor accepts source code as input and is responsible for
For example
The C compiler translates source to assembly code. The source code is received from the preprocessor.
The assembler creates object code. On a UNIX system you may see files with a .o suffix (.OBJ on MSDOS) to indicate object code files.
If a source file references library functions or functions defined in other source files the link editor combines these functions (with main()) to create an executable file. External Variable references resolved here also. More on this later (Chapter 34).
Now that we have a basic understanding of the compilation model we can now introduce some
useful and sometimes essential common compiler options. Again see the online man pages
and Appendix for further information and additional options.
cc file1.o file2.o ...... -o executable
cc calc.c -o calc -lm
Many other libraries are linked in this fashion (see below)
cc prog.c -L/home/myname/mylibs mylib.a
BY default, The preprocessor first searches for #include files in the directory containing source file, then in directories named with -I options (if any), and finally, in /usr/include. So to include header files stored in /home/myname/myheaders you would do:
cc prog.c -I/home/myname/myheaders
Note: System library header files are stored in a special place (/usr/include) and are not affected by the -I option. System header files and user header files are included in a slightly different manner (see Chapters 13 and 34)
For further information on general compiler options and the GNU compiler refer to
Appendix .
C is an extremely small language. Many of the functions of other languages are not included in C. e.g. No built in I/O, string handling or maths functions.
What use is C then?
C provides functionality through a rich set function libraries.
As a result most C implementations include standard libraries of functions for many facilities ( I/O etc.). For many practical purposes these may be regarded as being part of C. But they may vary from machine to machine. (cf Borland C for a PC to UNIX C).
A programmer can also develop his or her own function libraries and also include special purpose third party libraries (e.g. NAG, PHIGS).
All libraries (except standard I/O) need to be explicitly linked in with the -l and, possibly, -L compiler options described above.
The UNIX system provides a large number of C functions as libraries. Some of these implement frequently used operations, while others are very specialised in their application.
Do Not Reinvent Wheels: It is wise for programmers to check whether a library function is available to perform a task before writing their own version. This will reduce program development time. The library functions have been tested, so they are more likely to be correct than any function which the programmer might write. This will save time when debugging the program.
Later chapters deal with all important standard library issues and other common system libraries.
The UNIX manual has an entry for all available functions. Function documentation is stored in section 3 of the manual, and there are many other useful system calls in section 2. If you already know the name of the function you want, you can read the page by typing (to find about sqrt):
man 3 sqrt
If you don't know the name of the function, a full list is included in the introductory page for section 3 of the manual. To read this, type
man 3 intro
There are approximately 700 functions described here. This number tends to increase with each upgrade of the system.
On any manual page, the SYNOPSIS section will include information on the use of the function. For example:
#include <time.h> char *ctime(time_t *clock)
This means that you must have
#include <time.h>
in your file before you call ctime. And that function ctime takes a pointer to type time_t as an argument, and returns a string (char *). time_t will probably be defined in the same manual page.
The DESCRIPTION section will then give a short description of what the function does. For example:
ctime() converts a long integer, pointed to by clock, to a 26-character string of the form produced by asctime().
You will soon discover (if you have not already) that the C compiler is pretty vague in many aspects of checking program correctness, particularly in type checking. Careful use of prototyping of functions can assist modern C compilers in this task. However, There is still no guarantee that once you have successfully compiled your program that it will run correctly.
The UNIX utility lint can assist in checking for a multitude of programming errors. Check out the online manual pages (man lint) for complete details of lint. It is well worth the effort as it can help save many hours debugging your C code.
To run lint simply enter the command:
lint myprog.c.
Lint is particularly good at checking type checking of variable and function assignments, efficiency, unused variables and function identifiers, unreachable code and possibly memory leaks. There are many useful options to help control lint (see man lint).
Exercise 12171
Enter, compile and run the following program:
main()
{ int i;
printf("\t Number \t\t Square of Number\n\n");
for (i=0; i<=25;++i)
printf("\t %d \t\t\t %d \n",i,i*i);
}
Exercise 12172
The following program uses the math library. Enter compile and run it correctly.
#include <math.h>
main()
{ int i;
printf("\t Number \t\t Square Root of Number\n\n");
for (i=0; i<=360; ++i)
printf("\t %d \t\t\t %d \n",i, sqrt((double) i));
}
Exercise 12173
Look in /lib and /usr/lib and see what libraries are available.
Exercise 12174
Look in /usr/include and see what header files are available.
Exercise 12175
Suppose you have a C program whose main function is in main.c and has other functions in the files input.c and output.c:
Exercise 12176
Suppose you have a C program composed of several separate files, and they include one another as shown below:
| File | Include Files |
| main.c | stdio.h, process1.h |
| input.c | stdio.h, list.h |
| output.c | stdio.h |
| process1.c | stdio.h, process1.h |
| process2.c | stdio.h, list.h |