Systems Programming/ C and UNIX Alice E. Fischer September 9, 2015 Alice E. Fischer Systems Programming { Lecture 3. 1/40 September 9, 2015 1 / 40 Outline 1 Compile and Run 2 Unix Topics System Calls The Unix File System Directories and Files I-Nodes 3 Directory Operations 4 Summary Alice E. Fischer Systems Programming { Lecture 3. 2/40 September 9, 2015 2 / 40 Outline Coding Standards Part of every program grade will be based on these coding standards: Keep all functions short. 30 lines is normally too long. Global variables and use of goto are permanently forbidden. Use class member variables and local variables appropriately. Test data should be submitted and should test all parts of the program. Write your code so that it conforms to the style standards on the next slide. Alice E. Fischer Systems Programming { Lecture 3. 3/40 September 9, 2015 3 / 40 Outline Style Standards Keep your code and your comments within 80 columns. Eliminate unnecessary words from your comments. Do not repeat the obvious. Comments are for ideas that are not obvious. Use appropriate whitespace, not too little, not too much. Put a space after every comma, semicolon, //, and anywhere else that will help to break up the words in your statement. Do not put blank lines randomly all over the code. Do not put multiple consecutive blank lines in your file. If you need a visual divider, use a line of //|||||{ Spelling and grammar need to be correct. Abbreviations are OK. Outright misspellings are not. Indentation must be consistent. Learn how to use your IDE to do this. The indentation style should be one of the two nationally recognized styles for C. Indent 3 or 4 spaces at every level. Not less, not more. Alice E. Fischer Systems Programming { Lecture 3. 4/40 September 9, 2015 4 / 40 Outline Using the Tools Attached to the website are two files, tools.cpp, and tools.hpp. Download and save the pair. Please use the functions in the tools module as follows: In tools.hpp, put your own name on line 9. Call banner() or fbanner() or both at the beginning of each program you write. This will put a standard header on the output. Call fatal( format, output-list ); to exit the program after a fatal error. It flushes the streams and exits properly. Use hold() if you want to pause execution so you can read the output screen. Do not use a system call or anything non-standard. Study the code in the fatal() function until you understand how variable-length argument lists work. Please read the relevant section of the handout from the first week (Chapter 20). Alice E. Fischer Systems Programming { Lecture 3. 5/40 September 9, 2015 5 / 40 Compile and Run The Command Shell Stages of Compilation Conditional Compilation Linking Alice E. Fischer Systems Programming { Lecture 3. 6/40 September 9, 2015 6 / 40 Compile and Run Stages of Compilation Between submitting your source code to the compiler and running your program, these things must happen: The preprocessor is used in four ways: Lexical analysis: the words and symbols in your code are identified. Preprocessing: conditional compilation, include files, macros, and constant definitions are removed from the code and replaced by compilable code. Compilation: Your code is parsed and converted to object code. Linking: Modules of your program are combined into a load module, and linked to the system libraries. Loading: The executable file is loaded into main memory and its process is put on the system's run queue. Alice E. Fischer Systems Programming { Lecture 3. 7/40 September 9, 2015 7 / 40 Compile and Run The Preprocessor Both C and C++ have a preprocessor, with its own language that is quite separate from the programming language. The preprocessor is used in four ways: To include header files for code modules: #include <string> To define and un-define symbols and literal constants: #define UNIX To define macros: short, untyped, inline functions. These were important in C, but have largely been replaced by inline functions with full type-checking in C++. To do conditional compilation, which is used to create portable code modules. Preprocessing happens after lexical analysis and before compilation. Alice E. Fischer Systems Programming { Lecture 3. 8/40 September 9, 2015 8 / 40 Compile and Run Conditional Compilation Conditional compilation enables us to \make" a single source code module in multiple ways that are appropriate for different OS and hardware architectures. When you download source code for a major software project, it will be full of conditional compilation blocks. The top-level blocks will include other files that are also full of conditional compilation blocks. It soon becomes difficult to figure out what code is being compiled! Alice E. Fischer Systems Programming { Lecture 3. 9/40 September 9, 2015 9 / 40 Compile and Run Conditional Compilation Directives These directives include or exclude a block of code from the current module during the current compile. Excluded code is not compiled. #ifdef SYMBOL If the SYMBOL is defined, the following code block will be compiled. #ifndef SYMBOL If the SYMBOL is not defined, the following code block will be compiled. #if followed by a constant expression. The if-condition is tested. When true, the lines of code up to the matching #endif are included in the program. When false, they are skipped (not compiled). #if can be used with the keywords “defined” or “!defined” #if defined (SYMBOL) and #if !defined (SYMBOL) #elif constant-expression and #else Any number of #elif and one final #else can follow the #if. #endif is used with #ifdef, #ifndef, and #if Alice E. Fischer Systems Programming { Lecture 3. 10/40 September 9, 2015 10 / 40 Compile and Run Conditional Compilation{Continued Include-guards are the most common use of conditional compilation. An include guard is a preprocessor command (or command combo) that will include or exclude a block of code based on what has previously been included. Include guards are used to ensure that no block of code is included twice in the same compile module. Every header file should be protected by include guards. Three processor commands are needed: #ifndef MODULE_NAME #define MODULE_NAME ... code for the module ... #endif An alternative that is supported by some, but not all, systems is #pragma once Alice E. Fischer Systems Programming { Lecture 3. 11/40 September 9, 2015 11 / 40 Compile and Run Linking At link-time, system and local libraries are searched for functions that were called by the program. (See bottom of log.txt). User functions are linked statically: the entry point of the function is stored in the transfer vector of the module that calls it. System functions are linked dynamically: a stub function is hard-linked into the code. The actual function code is brought in at load time, if it is not already there. If some other process has already loaded the needed function, your process will be linked to the same copy. To make this work, system code must be reentrant, that is, the code must not modify itself at run time. Alice E. Fischer Systems Programming { Lecture 3. 12/40 September 9, 2015 12 / 40 Unix Topics Unix Topics System Calls vs. Library Function Calls The Unix File System Directories and Files Directory Operations Alice E. Fischer Systems Programming { Lecture 3. 13/40 September 9, 2015 13 / 40 Unix Topics System Calls System Calls vs. Library Function Calls A system call is a call to a function that executes with root privileges. They are documented in section 2 of the Unix manual. Library function calls execute with user privileges. (Therefore, they are less dangerous.) A library function sometimes calls a system function, causing a context switch: The user's process (in the OS) goes from RUN state to BLOCKED state. Control is transferred to the system function, which has its own stack and environment, and runs in supervisor mode. The system function reaches back into the user's stack to get its parameters. When execution is finished, the user's process moves into the READY state. System calls cause two context swaps. System calls may not be portable because systems are different. Alice E. Fischer Systems Programming { Lecture 3. 14/40 September 9, 2015 14 / 40 Unix Topics System Calls The OS Process Queue Starting Done login or my turn termination execve READY RUN time is up system call completion or I/O BLOCKED A system call takes your process out of RUN. It stays in BLOCKED until the system call finishes. Frequent system calls will affect performance. Alice E. Fischer Systems Programming { Lecture 3. 15/40 September 9, 2015 15 / 40 Unix Topics The Unix File System The Unix File System Mounted file systems The UNIX root and bin directories Directories, files, and pathnames Links and iNodes System libraries for directory processing. Alice E. Fischer Systems Programming { Lecture 3. 16/40 September 9, 2015 16 / 40 Unix Topics The Unix File System Hardware { Unix System { Program 3451716 John's file 2 links data data 6 blocks data Mary's link to data John’s file data data Alice E. Fischer Systems Programming { Lecture 3. 17/40 September 9, 2015 17 / 40 Unix Topics The Unix File System A Fully Mounted File System Windows pathnames all start with a device code, such as C: Unix pathnames don't. All Unix pathnames start at the root directory, which is written as: / A removable device that stores files (disk, CD-ROM, stick memory) must be mounted before use. For this purpose, several mount points (empty directories) are built into the Unix file system.