Project 0
Warm-Up

INTRODUCTION:

It is not uncommon for students come into this course without basic C software development skills (which should have been developed in the CS111 prerequisites), and invest a great deal of time and frustrating effort in the first two projects before concluding they will not pass the course and must drop. We have created this simple warm-up to determine whether or not students are prepared to work on C programming projects. Most students should find this project to be relatively easy (a few hours of work, mostly understanding the APIs). If you do not find this project to be relatively straight-forward, you may want to reconsider whether or not you are ready to take this course.

RELATION TO READING AND LECTURES:

None. This project requires only C programming skills and basic familiarity with command line interfaces and makefiles that incoming students should already possess. Mastery of the material covered in a class like 35L should be enough to make this project straightforward.

PROJECT OBJECTIVES:

DELIVERABLES:

A single compressed tarball (.tar.gz) containing:

PROJECT DESCRIPTION:

  1. (if you do not already have one) bring up or obtain access to a Linux development environment. Your development environment should include (at least):
  2. (if you are not already familiar with them) study the following manual sections:

    You will probably find understanding getopt(3) to be the most difficult part of this project. Feel free to seek out other examples/tutorials for these functions, but make sure you cite those sources in your README.

  3. write a program that copies its standard input to its standard output by read(2)-ing from file descriptor 0 (until encountering an end of file) and write(2)-ing to file descriptor 1. If no errors (other than EOF) are encountered, your program should exit(2) with a return code of 0.

    Your program executable should be called lab0, and accept the following (optional) command line arguments (in any combination or order):

    When you print out an error message (e.g., because an open failed), your message should include enough information to enable a user to understand not merely the nature of the problem but its cause ... for example:

    Do your argument parsing with getopt_long(3). This is, for historical reasons, a somewhat convoluted API, but ...

    If you encounter an unrecognized argument you should print out an error message including a correct usage line, and exit(2) with a return code of 1.

  4. To ensure that operations are performed in the right order when multiple arguments are specified, it is suggested that you

    It is relatively easy to generate primitive error messages with perror(3), but if you study the documentation you will see how to get access to the underlying error descriptions, which you could then use with fprintf(stderr,... to generate better formatted error messages to the correct file descriptor.

    Note that to use the advanced debugging features of gdb(1) you will need to compile your program with the -g option, which adds debugging symbol table information to your program.

  5. create a Makefile that supports the following targets:
  6. run your program (with the --segfault argument) under gdb(1)

    Putting the code that causes the SEGFAULT in a separate subroutine will make the stack trace a little more interesting.

  7. run your program (with the --segfault argument) under gdb(1)

    You will not be able to list lines of code, print data, or set breakpoints in gdb unless your program has been compiled with the -g (debug symbols) switch.

Summary of exit codes

SUBMISSION:

Your README file (for this and every lab) must include lines of the form:

And, if slip days are allowed on this project, and you want to use some, this too must be included in the README file: If, for instance, you wanted to use two slip-days, you would add the following line: Your name, student ID, and email address should also appear as comments at the top of your Makefile and each source file.

Your tarball should have a name of the form lab0-yourStudentID.tar.gz. You can sanity check your submission with this test script. There will be no manual regrading on this project. Submissions that do not pass the sanity check are likely to receive very low scores.

We will test it on a departmental Linux server. You would be well advised to test all the functionality of your submission on that platform before submitting it.

GRADING:

Points for this project will be awarded:

Value Feature
packaging and build
5% untars expected contents
5% clean build w/default action
1% correct make check
1% correct make clean
1% correct make dist
2% reasonability of README contents
5% reasonability of check smoke test
input/output features
10% correctly copy input to output
5% correctly implements --input
5% correctly implements --output
5% implements combined --input + --output
5% correct handling of un-openable/creatable output file
5% correct handling of non-existant input file
5% correct handling of invalid arguments
fault handling
5% generate (and die from) SIGSEGV
5% catch and report SIGSEGV
gdb use
5% screen shot showing taking of segfault within gdb
5% screen shot showing backtrace from segfault
5% screen shot showing breakpoint stop before fault
5% screen shot showing inspection of null pointer
code/package review
2% correct argument processing
2% correct file descriptor handling
2% correct signal handling
4% misc