Programming Projects
Due at midnight on the specified due date. All projects must conform to the style guidelines for this class (see below).
- Due Tuesday, September 1: bcount - count the occurrences of a specified byte in a file. Individual project.
- Due Thursday, September 17: slush - the SLU shell. Work in pairs.
- Due Tuesday, September 29: crack - multithreaded brute-force password hash cracker. Individual project.
- Due Wednesday, October 14 (in class): elevators - elevator simulation. Work in pairs.
- Due Thursday, November 5: malloc -Dynamic memory allocation routines. Individual project. (Also see additional notes)
- Due Monday, November 23: proxy - An HTTP proxy server. Work in pairs. (Also see additional notes)
- Due Thursday, December 10: longls -List files in a directory, with details. Individual project.
OS Source Code Guidelines
File Naming and Compilation
Programming assignments will have a standard name, specified on the assignment handout. Your final product should compile without errors or warnings with the command
"make [name]", where [name] is the assignment name. For example, the bcount assignment should compile with "make bcount".
For simple assignments, you can accomplish this simply by naming your source file [name].c for C programs or [name].C or [name].cpp for C++ programs.
For more complicated assignments (with multiple files or that need linked libraries), you'll need to write a makefile with an appropriate target.
Source Code Commenting
Source code for each project needs to be commented. Each file must have a header comment that includes your name, the date, and a brief description of the purpose of that file.
Each function should have a header comment that includes at least the followwing information:
- Function name
- A brief description of what the function is doing
- Inputs, outputs, and return values.
Comments are often said to be either strategic or tactical. A strategic comment describes what a function or section of code is intended to do, and is placed before this code. A tactical comment describes what a single line of code is intended to do, and is placed, if possible, at the end of this line. Too many tactical comments can make code unreadable. For this reason, it is recommended to primarily use strategic comments, unless trying to explain very complicated code.
Style
Your code should have a consistent and readable style.
For example, read the
Linux kernel
coding style guidelines.
The text editor you use should assist and/or enforce indentation.
If your editor doesn't help with indentation, it's time to learn a decent
editor, such as emacs.
Error Checking
The following need to be error-checked in all programs:
- Number of command line arguments
- Command line argument values
- Return values of system calls that might fail.
If an error occurs make sure to output a meaningful error message to stderr/cerr and have your program exit gracefully.
