CS 11: Advanced C track

This is the home page for the advanced C track of CS 11. This information is for the spring 2004 term.

NOTE: This track is UNDER CONSTRUCTION! Hopefully one day it will be complete ;-)

Administrative information

Prerequisites

In order to take this track, you must have either:

taken and passed the CS 11 C track, or
have a reasonable amount of C programming experience

or both.

If you are not sure what constitutes a reasonable amount of programming experience, look at the assignments for the C track. If any of them seem even remotely challenging to you, you should not be in this track. I will assume that anyone taking this track has mastered all of the material in the C track, except possibly for the material on Makefiles. I will also expect that you know how to use a C debugger (such as gdb). If you don't, you should read this page. Knowing how to use a debugger will be an essential skill for this track.

You also need to have a reasonable familiarity with Unix to take this track. All assignments will be run on Unix systems, and several will involve Unix-specific system calls. You should be very comfortable with all basic Unix commands, as well as text editing (I recommend emacs, which is the best code editor, but this is not required), and use of a C compiler (ideally gcc, which is the compiler we will be using). You do not have to understand Unix system calls, as we will cover that material as we get to it.

Note that compared to most of the other CS 11 tracks, this track requires much more "programming maturity". If you need or expect a lot of hand-holding, you should definitely not take this track. This track is for serious programmers who are comfortable with the following kinds of activities:

reading man pages
searching the internet for information (including newsgroups and mailing lists)
reading programming-related books
writing clear, well-documented and maintainable code

Some of the material will be quite challenging, and I cannot guarantee that each assignment will only take three hours a week, but I will aim for that level. If any of this seems intimidating, or if you only want to take CS 11 for easy credits, don't take this track.

Finally, you must have an account on the CS cluster. If you do not have such an account, please get one at http://www.cs.caltech.edu/cgi-bin/sysadmin/account_request.cgi before submitting the first lab.

Instructor

The instructor is Mike Vanier (mvanier@cs.caltech.edu). My office is in Jorgensen room 154a.

My office hours

My office hours are on Friday from noon to 2 PM.

However, feel free to drop in to my office at any time. I'm unlikely to be in in the mornings, but I'm often around fairly late at night. If you need to meet with me outside of office hours, sending me email is a good idea.

Minilectures

Minilectures will be held on Wednesdays at 4:45 PM in room 287 of the Jorgensen building.

Minilectures will typically last about an hour. Attendance is optional; if you can do the work without minilectures, it's fine with me. However, since this track covers some fairly complex material, I strongly suggest that you attend.

Grading policy

The course is pass-fail. I will grade each assignment on a scale of 0 to 10. All assignments are due one week after they are assigned. Late assignments will lose one mark for each day they are late (all the way to zero). If the assignment doesn't meet my standards, I will require you to redo it (see below).

In special cases, I may grant extensions on homework to individuals in special circumstances. The duration of the extension will depend on how compelling the reason for the extension is.

All assignments must be completed in order to pass the course, regardless of the numerical grade you get. If you're heading for an F, I will encourage you to drop the course so as not to hurt your academic record. If you have more than two assignments that haven't been completed satisfactorily by the time I have to submit the grades, you will get an F. If you have only one or two incomplete assignments I may give you an E instead, but you will have to complete the assignments as soon as possible.

Collaboration policy

You are welcome to collaborate informally on your assignments with other individuals who are taking or have taken the class, but you must write all of your own code. Copying another student's code verbatim or nearly verbatim is not acceptable. Getting advice on algorithms or (say) syntactic details of the language is fine.

Submitting assignments

Make a subdirectory of your UGCS directory called ~/cs11. In this directory, create another directory called advanced_c. Put the files for each week's assignments in a separate subdirectory called lab1, lab2, etc. I will collect the assignments on the day that they're due. If your assignment is not ready, let me know by email and also let me know when it's ready to be graded. I'll send you grades and comments by email.

Redoing assignments

I will make you redo assignments under circumstances which include at a minimum (but are not restricted to) any of:

a program which does not compile
a bug in the program
a program which violates the specifications
severe style violations (unreadable code)

If this happens, the redone assignment is due one week after I've requested the redo (though I'd prefer if you completed it earlier). I will not grade assignments that I've asked to be redone until they are completed to my satisfaction. I will deduct from 1 to 5 marks from the grade as a redo penalty (depending on how much needs to be redone). If the redo still doesn't meet my standards, I may ask for a second redo, which will also be penalized accordingly. It is extremely unlikely that I will ask for a third or further redo, but I reserve the right to do so. If a redo is late, the assignment will be graded at 0. If an assignment needs to be redone, you must notify me by email when it's ready. If you don't notify me, I will assume that it isn't ready and grade accordingly. Redone assignments should be placed in the same location as the original assignment, overwriting the old files if necessary.

How assignments are graded

I will send you back a copy of your code with in-line comments. My comments will look like this:

    /*** THIS IS ONE OF MY COMMENTS (ALL UPPER CASE, 3 ASTERISKS AT LEFT).
     ***/

Please don't write your own comments in this style (at least for the duration of this course). For style (code formatting) issues I will sometimes identify the problem via a tag that can be looked up in the C style guide. An example might be:

    /*** STYLE: [STMTS_ON_LINE] ***/
    i = 1; j = 2; k = 3;

which says to look in the style guide for the style violation called [STMTS_ON_LINE]. If you do that you'll see that I don't like to see more than one statement on a line. Poor code formatting is so common that this notation saves me a lot of work, as well as forces you to read the style guide. In addition, there is also a C style checking program which you will use to check the style of your code. This will give you instant feedback in a way that I can't, but it won't catch all style violations. Compared to most instructors, I am very picky about code formatting, so please use the style checker; it'll save you a lot of time. I will be especially severe for the most common style mistakes described in the style guide, and will not hesitate to make you rewrite code that violates these guidelines.

Late adds

I usually allow the course to be added up to add day; the specific choice will depend on my impression of the student's abilities. When a student adds the course, all assignments that have been assigned up to that point are due at the due date for the current assignment. This will be difficult for this track. Normal late penalties apply with respect to these due dates.

Auditing

I welcome auditors. If I have time, I will grade assignments submitted by auditors. However, this grading has very low priority and may not happen (or may not be up to my usual grading standards, or may not be returned promptly).

Programming "gems"

If I see any submissions that strike me as particularly outstanding, I will post them on a special web page for this track. Examples of such programming "gems" might include:

Code that is significantly better than my solution ;-)
Extremely elegant and/or efficient solutions to a particular problem.
Code that is superbly readable and comprehensible.
Code that goes above and beyond the requirements of the lab.
Code that does something really cool.

This is your chance to impress me with what a great programmer you are. However, since this course is pass/fail, there is no extra credit for creating a gem; you have to do it simply because you want to.

Compiler warnings

Please use the following command-line options when compiling your C code:

% gcc -Wall -Wstrict-prototypes ...

This will help you avoid many obvious problems. All submitted code must compile without warnings, except in special cases (e.g. lexers and parser generators sometimes create code that generates compiler warnings that can't be easily removed).

Interestingly, I strongly suggest that you do not use the compiler options -ansi -pedantic, which I require in the C track. The reason for this is that on Linux systems, those compiler options interact badly with header files for obscure reasons, often forcing you do manually declare prototypes for functions which should be in the standard header files. So don't use those options.

Topics to be covered

The topics to be covered can vary from term to term, but they fall into three broad classes:

dusty corners of the C language:
- enum and union types
- function pointers and typedef
- the dreaded goto statement
- varargs (variable-length argument lists)
- #ifdef, #if defined(X), and other preprocessor fun
- setjmp(), longjmp()
- inline assembly language code
programming tools:
- make and Makefiles
- memory checkers such as valgrind
- conservative garbage collection
- getopt for command-line argument processing
- regular expressions
- the readline library for line editing (useful in interactive interpreters, for instance)
- parser generators (flex and bison)
Unix programming and system calls:
- TCP/IP sockets (communication over the internet)
- output through pipes
- fork() and exec() (writing a simple command shell)
- getenv() and setenv()
- threads
- signals

Note that each lab will typically select a few topics from each category instead of covering any one category exhaustively. We will probably not cover all of these topics. Also, if you wish, you can suggest a topic to me, and if I like it I will create an assignment based on it.

Assignments

Grades

Legend:

Green means that the assignment was completed successfully.
Red means that the assignment is overdue.
Yellow means that the assignment needs to be redone.
A blank space means that the assignment isn't due yet.

lab1 lab2 lab3 lab4

assigned/due
4-7/4-21 4-14/4-28 4-28/5-12 5-5/5-19

Jimmy Jia (taion@its)

Alan Somers (somers@its)

Miscellaneous stuff

Please read all of these sections before doing the first lab, even if you already know the material.

The C style guide. This tells you how I want you to format your C code.
An introduction to the make program and Makefiles, which are extremely useful for multi-file projects.
A brief introduction to the gdb debugger.
A discussion on how to handle command-line arguments in your C programs.

References

Brian Kernighan and Dennis Ritchie, The C Programming Language, 2nd Ed.
This book, known as "K&R", is a concise, complete, and readable description of the C language. If you do not have this book, I strongly recommend you get a copy.
Bruce Molay, Understanding Unix/Linux Programming
This book, which I discovered by accident while browsing through the Caltech bookstore, gives very nice, readable descriptions of most of the material we'll cover in this track. I recommend you purchase a copy.
Peter van der Linden, Expert C Programming: Deep C Secrets
This book, despite having numerous typos, is one of the few books that explains what is going on at the machine level during compilation and execution of a C program. It has much more information than beginners require, but more advanced programmers should read it.
Brian Kernighan and Rob Pike, The Unix Programming Environment
This book, although very outdated, contains a lot of interesting information about Unix and its philosophy, and has a nice introduction to using lex, yacc and make to build an interpreted language. Note that nowadays most programmers use flex instead of lex and bison instead of yacc, but the programs are almost identical.
W. Richard Stevens, Advanced Programming in the UNIX Environment
This book is a classic tutorial and reference for Unix system calls. It's similar to the Molay book but more comprehensive and somewhat less friendly.
The development of the C language
The interesting history of how C came to be, from one of its creators (Dennis Ritchie).

	lab1	lab2	lab3	lab4
assigned/due	4-7/4-21	4-14/4-28	4-28/5-12	5-5/5-19
Jimmy Jia (taion@its)
Alan Somers (somers@its)