Spring Semester 2008

January 28, 2008 – May 2, 2008

Assignment 2: Horrible Cats

Out on: February 4, 2008
Due by: February 11, 2008, 11:00 am (before lecture)
Collaboration: None
Grading: Packaging 10%, Style 10%, Performance 10%, Design 10%, Functionality 60%

Overview

The second assignment is a semi-painful introduction to using system calls directly instead of using the standard C library.

Problem 1: Preparatory Words of Wisdom (10%)

A long time ago Rob Pike wrote a paper on "Unix Philosophy" that is somewhat germane to the rest of this assignment:

UNIX Style, or cat -v Considered Harmful

Read through the paper (and I mean the full paper, there's a PDF link near the top) and write a short reaction to it in your README file. Ideally you do this once before you start Problem 2 and then again after you're done with Problem 2. (You don't really have to it twice, but it's fun to have a "before and after" perspective on this stuff.)

Problem 2: The Cats of Ulthar (90%)

Your task, should you choose to accept it, is to rewrite the standard Unix cat command from scratch. The defining document for cat is the Linux man-page for cat on the ugradx.cs.jhu.edu reference machine. The horror referred to indirectly in the title of this problem is that you must use system calls for all your I/O! In general, you should minimize the number of C library calls in your code (although strcmp and stuff are of course okay; see also the Hints section below).

The more options from the man-page you implement the better. The faster your cat is the better. The smaller your cat is the better (both statically and at runtime of course). You get the picture. :-)

Hints

Deliverables

Please turn in a gzip compressed tarball of your assignment; the filename should be cs211-assign-2-login.tar.gz with login replaced by your Unix login name on ugradx.cs.jhu.edu (so I would use cs211-assign-2-phf.tar.gz). The tarball should contain no derived files whatsoever (i.e. no executable files), but allow building all derived files. Include a README file that briefly explains what your programs do and contains any other notes you want us to check out before grading. We expect that your Makefile handles "the usual" targets like clean and test aside from all (which is the main way we will build your program). Include other "common" files such as INSTALL describing how to install your tool, CREDITS to pay your respects to the people whose code you're reusing, and LICENSE to describe copyright and distribution terms if you feel like it. You can look at any number of "famous" open source projects to see what kind of structure is appropriate; gif2png is a relatively small example, but you don't need everything in there. Aside from your code, what you really need is a README and a Makefile that works. :-)

Grading

For reference, here is a short explanation of the grading criteria. Packaging refers to the proper organization of the stuff you hand in, following the guidelines for Deliverables above. Style refers to C programming style, including things like consistent indentation, appropriate identifiers, useful comments, suitable documentation, etc. Simple, clean, readable code is what you should be aiming for. Performance refers to the amount of resources your program needs to produce the required results; this can include space, time, and other metrics. Design refers to proper modularization and the proper choice of algorithms and data structures; often this can be judged by asking "How hard would it be to add feature X?" and "How hard is it to replace algorithm X with algorithm Y?". Functionality refers to your programs being able to do what they should according to the specification given above; if the specification is ambiguous and you had to make a certain choice, defend that choice in your README file; if the specification is too general and you had to add certain restrictions, defend those in your README file as well.

If your programs cannot be built on ugradx.cs.jhu.edu you will get no points whatsoever. If your programs cannot be built without warnings using gcc -ansi -pedantic -Wall -Wextra -std=c99 -O we will take off 10% (except if you document a very good reason). If your programs cannot be built using make we will take off 10%. If your programs fail miserably even once, i.e. terminate with an exception of any kind or dump core, we will take off 10%. Finally, make sure to include your name and email address in every file you turn in!