The project documents will be added to this page as they become available. If you get a page that says "not yet available," it should become available in the future. Ask about it only if we announced that it was supposed to be available.
Note:Files listed as "pdf" can be viewed or downloaded and printed at high-quality with Adobe's Acrobat Reader.
Files listed as text are plain ASCII text files. The should display in your browser with correct formatting, but can also be downloaded from the course file server; downloading with an ftp utility set to ASCII text mode is recommended for code and sample files to avoid problems involved with platform-specific end-of-line differences.
The header files below should be downloaded and used in your project as-is, without modification. These define the modules and their interfaces.
The comments in these files provide essential details on what each module and function does.
The source files named with "skeleton" provide code that your project must use, but you will add your own code to complete the file. See the comments in the file for instructions.
The following files are useful, but are not part of the specifications.
The following sample behavior files illustrate the program behavior and contain all of the different output message text strings produced by the program (see the strings.txt file). Your program should match these samples exactly so that you can be sure it is producing all of the different kinds of messages correctly. However, these samples are not a complete test of your program. Your program will be tested for a large number of other possible inputs and input sequences.
The console interaction files are a capture of the console display during the program run. The _in.txt and _out.txt files are for you to use with redirected I/O. When given the _in.txt file, your program's stdout output should match the _out.txt file exactly. The other output files are written during the by the program, and your program should produce files that match exactly with these samples.
The following sample illustrates the "normal" behavior of the program and contains the corresponding messages. Your program should reproduce the output files exactly.
There are output files for the two different implementations, showing that the only difference in program behavior is the items-allocated values.
The following sample shows the error messages produced by the program. Your program should reproduce the output file exactly. These are the same for both implementations.
The following sample illustrates the behavior of the program when you input strings that are too long or too short, or contain excess whitespace and use "type-ahead." Your program should reproduce the stdout files exactly.
These samples demonstrate the program behavior and are supposed to contain every possible type of output message string so that you can prevent your autograder score from being affected by spelling errors and typos.
These samples are not a complete test of your program!!! Your program will be tested for a large number of other possible inputs and input sequences. You must devise your own complete test set to find the bugs in your code.
The console outputs are a saved copy of a console window after entering the commands by hand. The stdin input file is suitable for redirecting input, and the stdout output can be compared with the redirected output of your program. Your program should match the stdout output.
See the course web page for how to compare files and redirect I/O. In the examples directory on the file server you can find the redirect_io module that you can use to redirect I/O from a C program on any platform. You can use this to help test your program's output against the supplied samples. The instructions are in the header file.
It is a good idea to test on your components as you develop them (see the project document). You can get an autograder evaluation of the components before you have finished the entire project. To do this, submit ALL of the required project files, even if they are empty. The autograder will build and test whatever parts of the program that it can - see the explanation of the autograder feedback below. Notice that the component tests generally will not work unless your p1_globals module is correct.
For a walkthrough on how to check your code before submitting and what the results of submitting should look like, see submit example.
For an explanation of the autograder feedback for this project, see AGoutput.
The Code Review for Project 1 covered important features of good code quality.
For your reference in understand the Code Quality scoring of your Project 1, and preparing for Project 3,
the samples prepared for the code review can be viewed at: