Project 1: Warm-up Project
Questions about the project? Send them to
Due: Wednesday, 9/16, by 9pm.
Before beginning: Read this tutorial. It has some useful tips for programming in the C environment.
This project must be done alone. You can talk to your colleagues about it, but every line of code must be written and understood by you. Of course, you can always ask the TAs and professors for help too.
The first project is simply a warm-up to get you used to how this whole project thing will go. It also serves to get you into the mindset of a C programmer, something you will become quite familiar with over the next few months. Good luck!
You will write a simple sorting program. This program should be invoked as follows:
shell% ./mysort test.txt
The above line means the users typed in the name of the sorting program
Proper input files should look like this:
10 hello 20 goodbye 17 working on the project? 15 are you
The goal of the sorting program is to read in the data from the specified
input file, sort it based on the key value in the first column, and output the
sorted result (keys and text) to the screen (standard output, or
10 hello 15 are you 17 working on the project? 20 goodbye
You should observe how the output file is sorted on the first column of numbers (10, 15, 17, 20), and the accompanying text is kept with the keyword that it was read in with. Sounds easy, right? It should. But there are a few details...
Assumptions and Errors
String length: You may assume no line in the input file is longer than 80 bytes. If you encounter a line that is too long, you should print error message
32-bit integer range. You may assume that the numbers are 32-bit integers, i.e. we will not test integers larger than 32 bits.
File length: You may not assume anything about the length of the file, i.e., it may be VERY long.
Invalid files: If the user specifies exactly one file (as desired) but it can't be opened (for whatever reason), the sort should print:
Too few or many arguments passed to program: If the user runs mysort without any arguments, or passes more than one file name to mysort, you should print
Only a number: Let's say there is a line that only has a number on it and nothing else. It is a valid line.
Lines with funny keys or empty lines or ... Empty lines, or lines with a funny key (e.g., a string, not an integer in the first column) should all be included in the final output as if they have a key value of 0. Thus, if you have an input file with a valid line with -1 as the key, an empty line, and then a valid line with 1 as the key, you should print out the -1 line, the empty line, and then the 1 line.
Negative numbers as keys. Should work.
Lines with leading space. Should work. The key should be preserved and not transformed into a zero. As always, the exact line should be preserved in the final output (with leading spaces and everything).
Line length: You should accept lines that fit into 80 characters, including end-of-line (\n) but not including the end-of-string delimiter (\0). For example, if the maximum line size was 6 (not 80), and you had this input file:1 22 333 4444 55555 666666You should accept 1 ... 55555 but not 666666. Seeing 666666 should cause your program to print an error and exit.
Valid key: A key of the form 123abc is not valid. Thus, after parsing the line with
Important: On any error code, you should print the error to the screen
To exit, call
For reading in the input file, the following routines will make your life
For parsing each line, you may find
If you don't know how to use these functions, use the man pages. For
Start small, and get things working incrementally. For example, first get a program that simply reads in the input file, one line at a time, and prints out what it reads in. Then, slowly add features and test them as you go.
For example, the way I wrote this code was first to write some code that
Testing is critical. One great programmer I once knew said you have to write 5-10 lines of test code for every line of code you produce; testing your code to make sure it works is crucial. Write tests to see if your code handles all the cases you think it should. Be as comprehensive as you can be. Of course, when grading your projects, we will be. Thus, it is better if you find your bugs first, before we do.
Keep old versions around. Keep copies of older versions of your program
around, as you may introduce bugs and not be able to easily undo them. A
simple way to do this is to keep copies around, by explicitly making copies of
the file at various points during development. For example, let's say you get
a simple version of
Keep your source code in a private directory. An easy way to do this is
to log into your account and first change directories into
Handing It In
You should turn in TWO files. The first, containing your code, should be
so make sure it compiles in such a manner.
You should also include a file called
You should copy these two files into your handin directory. These will be
or more succinctly:shell% cp mysort.c ~cs537-1/handin/remzi/p1/ shell% cp README ~cs537-1/handin/remzi/p1/
(the copy utility knows that if the last thing specified is a directory, it should just copy the files into that directory and give them the same names. Read the man page for