You are on page 1of 6

System Call : 1) A system call is the mechanism used by an application program to request service from the operating system.

2) These are tiny programs which are attached with the operating system which are call automatically by the call of some specific processes. 3) These are type routines which are called via process itself. System Call Function 1. system call is a subroutine which Function is a sub program which is going to internally interacts with the kernel return a value which is operated by the os. 2. system calls are provided by the Library calls include the ANSI C standard system and are executed in the library and are therefore portable. These system kernel. They are entry points functions are linked into your program into the kernel and are therefore NOT linked into your program. These are not portable calls 3. Time overhead in calling the system which is not required in case of function call stince a transition has to take call. place between user mode and kernel mode. 4. system call differ from one OS to the function calls are not. the other they are system dependent 5. system calls are executed in kernel library routines are executed in user address space address space. 6. execution of system call system has supervisor mode Not required to go in privilege mode(supervisor mode). 7. security vulnerability are lower in security vulnerability are higher in library system calls than library functions functions than system calls
System calls can fail in many ways. For example:

* The system can run out of resources (or the program can exceed the resource limits enforced by the system of a single program). For example, the program might try to allocate too much memory, to write too much to a disk, or to open too many files at the same time. * Linux may block a certain system call when a program attempts to perform an operation for which it does not have permission. For example, a program might attempt to write to a file marked read-only, to access the memory of another process, or to kill another users program. * The arguments to a system call might be invalid, either because the user provided invalid input or because of a program bug. For instance, the program might pass an invalid memory address or an invalid file descriptor to a system

call. Or, a program might attempt to open a directory as an ordinary file, or might pass the name of an ordinary file to a system call that expects a directory. * A system call can fail for reasons external to a program.This happens most often when a system call accesses a hardware device.The device might be faulty or might not support a particular operation, or perhaps a disk is not inserted in the drive. * A system call can sometimes be interrupted by an external event, such as the delivery of a signal.This might not indicate outright failure, but it is the responsibility of the calling program to restart the system call, if desired.
Mkstemp

The mkstemp function creates a unique temporary filename from a filename template,creates the file with permissions so that only the current user can access it, and opens the file for read/write.The filename template is a character string ending with XXXXXX (six capital Xs); mkstemp replaces the Xs with characters so that the filename is unique. The return value is a file descriptor; use the write family of functions to write to the temporary file. Temporary files created with mkstemp are not deleted automatically. The unlink function removes the directory entry corresponding to a file, but because files in a file system are referencecounted, the file itself is not removed until there are no open file descriptors for that file, either.This way, your program may continue to use the temporary file, and the file goes away automatically as soon as you close the file descriptor. Because Linux closes file descriptors when a program ends, the temporary file will be removed even if your program terminates abnormally. Ex:
char temp_filename[] = /tmp/temp_file.XXXXXX; int fd = mkstemp (temp_filename); /* Unlink the file immediately, so that it will be removed when the file descriptor is closed. */ unlink (temp_filename); /* Write the number of bytes to the file first. */ write (fd, &length, sizeof (length));

assert

It helps to find bugs earlier in the development and testing cycles.assert macro.The argument to this macro is a Boolean expression.The program is terminated if the expression evaluates to false, after printing an error message containing the source file and line number and the text of the expression.

Some good places to use

assert

are these:

* Check against null pointers, for instance, as invalid function arguments.The error message generated by {assert (pointer != NULL)}, Assertion pointer != ((void *)0) failed. is more informative than the error message that would result if your program * Check conditions on function parameter values. For instance, if a function should be called only with a positive value for parameter foo, use this at the beginning of the function body: assert (foo > 0); This will help you detect misuses of the function, and it also makes it very clear to someone reading the functions source code that there is a restriction on the parameters value. Archives An archive (or static library) is simply a collection of object files stored as a single file. (An archive is roughly the equivalent of a Windows .LIB file.) When you provide an archive to the linker, the linker searches the archive for the object files it needs,extracts them, and links them into your program much as if you had provided those object files directly. You can create an archive using the ar command.Archive files traditionally use a .a extension rather than the .o extension used by ordinary object files. Heres how you would combine test1.o and test2.o into a single libtest.a archive: % ar cr libtest.a test1.o test2.o The cr flags tell ar to create the archive Make File a text file that contains all of the commands required to build software projects. The makefile also constitutes a database of dependency information for your projects, allowing you automatically to verify that all of the files necessary for building a program are available each time you start a build. A makefile is a text file database.containing rules that tell make what to build and how to build it. A rule consists of the following: A target, the "thing" make ultimately tries to create A list of one or more dependencies, usually files, required to build the target A list of commands to execute in order to create the target from the specified dependencies When invoked, GNU make looks for a file named GNUmakefile, makefile, or Makefile, in that order. For some reason, most Linux programmers use the last form, Makefile. Makefile rules have the general form
target: dependency [dependency] [ . . . ]

command [command] [ . . . ]

target is usually the binary or object file you want created. dependency is a list of one or more files required as input in order to create target. The commands are the steps, such as compiler invocations or shell commands, necessary to create target. Unless specified otherwise, make does all of its work in the current working directory Example This sample makefile will make the discussion more concrete. It is the makefile for building a text editor imaginatively named editor.
# # Makefile.1 # editor : editor.o screen.o keyboard.o gcc -o editor editor.o screen.o keyboard.o editor.o : editor.c editor.h keyboard.h screen.h gcc -c editor.c screen.o : screen.c screen.h gcc -c screen.c keyboard.o : keyboard.c keyboard.h gcc -c keyboard.c clean: rm editor *.o

To compile editor, you would simply type make in the directory containing the makefile. It's that simple. Variables To simplify makefile editing and maintenance, make allows you to create and use variables. A variable is simply a name defned in a makefile that represents a string of text; this text is called the variable's value. Make distinguishes between four kinds of variables: 1.user-defined variables,2. environment variables, 3.automatic variables, and 4.predefined variables. Their usage is identical. Variables are usually defined at the top of a makefile. User-Defined Define variables using the general form:
VARNAME = value [ . . . Access using $(VARNAHE)

make actually uses two kinds of variables, recursively expanded and simply expanded Recursively expanded CC=gcc CC=$(cc) -g Simply expanded CC:=gcc CC += -g Environment variables Environment variables are make's copies of all the shell's environment variables e Ex: $home Automatic Variables Automatic variables are variables whose values are evaluated each time a rule is executed, based on the target and the dependencies of that rule.
Variable Description $@ Represents the target filename in a rule $* Represents the basename (or stem) of a filename $< Represents the filename of a rule's first dependency $^ Expands to a space-delimited list of all of a rule's dependencies $? Expands to a space-delimited list of all of a rule's dependencies that are newer than the target $ (@D) If the named target is in a subdirectory, this represents the directory part of the target's pathname $ (@F) If the named target is in a subdirectory, this represents the filename part of a target's pathname

Predefined Variables In addition to the automatic variables listed in Table 2.2, GNU make predefines a number of other variables that are used either as names of programs or to pass flags and arguments to these programs. Table 2.3 lists make's most commonly used predefined variables. You have already seen some of these in this chapter's example makefiles.
Variable Description Default Value Variable Description Default Value AR Filename of the archive maintenance program ar AS Filename of the assembler as CC Filename of the C compiler cc CPP Filename of the C Prepocessor cpp RM Program to remove files rm -f ARFLAGS Flags for the archive maintenance program rv ASFLAGS Flags for the assembler No default CFLAGS Flags for the C compiler No default

CPPFLAGS Flags for the C preprocessor No default LDFLAGS Flags for the linker No default

You might also like