COMP 530: Lab 0: C Refresher

This lab will be a quick refresher on C programming on Linux, and will serve as a warm-up for more intensive programming assignments this semester. You will need to complete these assignments on a department Linux machine.

Github classroom

The files you will need for this and subsequent lab assignments in this course are distributed using the Git version control system.

This semester, we will use github classroom to hand-out and submit assignment. This means you will need to create an account at github.com (if you don't have one already) and send the instructor your github user ID ASAP. If you create a new account you will need to verify your email address. Once you are invited to join the class, you will need to authorize github classroom to access your account.

Getting familiar with git

Git is a powerful, but tricky, version control system. We highly recommend taking time to understand git so that you will be comfortable using it during the labs. We recommend the following resources to learn more about git:

Working in a group

You may complete this assignment alone or with as many teammates as you like, per the course collaboration policy. However, you are strongly encouraged to do this assignment alone, as it will be difficult to get all needed points if you do all assignments in a group, and subsequent assignments will be much harder than this one. Moreover, this assignment will also help you warm up on C programming, and is an important building block for future labs. You may form different groups for subsequent assignments.

Once you join the group, you will be asked to create a team, or join a team. Once a team is created, you can add members to your team.

Important: In your code, you should have a file called authors.txt with the onyens of each member of the team on a separate line. For example:

Getting the starter code

You will need to click on this link to create a private repository for your code.

Once you have a repository, you will need to clone your private repository (see the URL under the green "Clone or Download" button, after selecting "Use SSH". For instance, if your private repo is called lab0-team-don:

System for this course

For COMP 530, we will be using classroom.cs.unc.edu, which you can access via ssh. This system has all needed software for these labs. We will grade your assignments on classroom, so ensure that they work on classroom. We will not give partial credit for assignments that work on a different system, but do not work on classroom.

You are also welcome to install the needed software on your own laptop. The course staff is not available to help you debug your personal laptop configuration. If you do this, you should still check that your code works on classroom.

Pointer Refresher

One of the hardest parts of moving from programming in a higher-level language, like Java, to C is dealing with pointers. We will start with a few ungraded, but highly recommended, exercise to refresh your understanding of pointers.

Exercise 1. Read about programming with pointers in C. The best reference for the C language is The C Programming Language by Brian Kernighan and Dennis Ritchie (known as 'K&R'). We recommend that students purchase this book (here is an Amazon Link). There is a copy on reserve in the library.

Read 5.1 (Pointers and Addresses) through 5.5 (Character Pointers and Functions) in K&R. Then download the code for pointers.c, run it, and make sure you understand where all of the printed values come from. In particular, make sure you understand where the pointer addresses in lines 1 and 6 come from, how all the values in lines 2 through 4 get there, and why the values printed in line 5 are seemingly corrupted.

There are other references on pointers in C, though not as strongly recommended. A tutorial by Ted Jensen that cites K&R heavily is available in the course readings.

We also recommend reading the Ksplice pointer challenge as a way to test that you understand how pointer arithmetic and arrays work in C.

Warning: Unless you are already thoroughly versed in C, do not skip or even skim this reading exercise. If you do not really understand pointers in C, you will suffer untold pain and misery in subsequent labs, and then eventually come to understand them the hard way. Trust us; you don't want to find out what "the hard way" is.

Input Processing

The main part of the assignment will be to write a C program that reads in a stream of characters from standard input (i.e., the keyboard) and writes them as 80 character lines to standard output (i.e., the "screen") with the following changes:

For this program, a "line of input" is defined as any sequence of zero or more printable and "whitespace" characters (tabs, spaces, and newline characters). Each "80 character line" to be written to standard output is defined as 80 non-newline characters plus a newline character. (Thus, each "80-character line of output" you generate technically will consist of 81 characters.)

Your program should process lines of input until the end-of-file (EOF) is reached, at which point the program should terminate. Note that when reading input, the enter/return (newline) character is counted as an input character. That is, when reading from stdin, every character that is read is counted---including newlines, white-space characters, etc. Thus, an input string of 10 printable characters plus a enter/return (newline) character is an 11-character line of input (even though you only see 10 characters on the console).

Depending on the library function you use to read the input characters, you may need some variant of EOF to test for the end of the file. The libc read() function is actually simplest: returning zero when the end of file is reached.

Your program should output only 80 character lines (with a newline after each line). For example, if your program has read in a line of input and is waiting for more data in order to make an 80-character line for output, and end-of-file is reached on standard input, then the program should terminate without printing out the partial output line. In addition, your program should not output any user prompts, debugging information, status messages, etc. The only output your program should generate is zero or more 80-character lines.

Note that if you execute your program interactively ( i.e., you type in characters from the keyboard directly into your program), your output may be interleaved on the console (your terminal window) with the input. Do not concern yourself with this! This is perfectly fine. Just concentrate on ensuring that your program only outputs zero or more 80-character lines.

For the second requirement, pairs of percent signs should be replaced as they are seen in the input stream . Thus, the string "abc%%%def" contains only one pair of percents and should be converted to the string "abc*%def". The string "abc%%%%def" contains two pairs of percents and should be converted to the string "abc**def". In the edge case where a "%%" are the 80th and 81st character on a line, the output should be a "*" in the 80th position of the output.

The purpose of this assignment is to review the basics of the C programming language and the use of UNIX/Linux program development tools. As stated here, the problem has nothing to do with operating systems. A later assignment will build upon this assignment and turn it into an operating systems problem.

Exercise 2. (10 points) Complete the input processing exercise as described above.

Hint: You can generate an end-of-file (EOF) in an interactive shell with Control+d.

Word to the wise: When manually testing your code, if termination conditions are correct, it may seem that Ctrl-D, Ctrl-C, and Ctrl-Z do the same/similar things, seemingly ending the program and returning you to the shell. However, each does something different. Ctrl-D, as noted above, will generate the EOF character. Some terminals also behave such that Ctrl-D on a non-empty line will add whatever is on that line to your program without a trailing newline, which might be useful for testing inputs without newlines. Ctrl-C and Ctrl-Z are similar, in that they cause the program to stop running, but not using the same mechanism. Ctrl-C sends an interrupt signal (we will cover signals later in class) which causes the running program to terminate. Ctrl-Z sends the stop signal which causes the running program to suspend which allows it to be restarted later. Although Ctrl-C might be useful in the case that you forgot to add the end condition in your code and need to terminate your program, your final assignment must terminate on an EOF, or it won't receive full credit.

Hand-In Procedure

Type make handin in the lab directory. You may submit more than once; if you do this, the most recent submission will be graded. The way submission works is basically that you create a tag in git, which is then pushed to github. If you look at your lab page on github, you will see a pulldown list with "Branch: master". If you drop this list down, you will see an option to view tags. If you choose the tag handin, you will be able to view your submitted code and confirm that it is correct.

All programs will be tested on classroom.cs.unc.edu. All programs, unless otherwise specified, should be written to execute in the current working directory. Your correctness grade will be based solely on your program's performance on classroom.cs.unc.edu. Make sure your programs work on classroom!

Generally, unless the homework assignment specifies otherwise, you should compile your program using the provided Makefile (e.g., by just typing make on the console). Do not add any special command line arguments ("flags") or compiler options to the Makefile.

The program should be neatly formatted (i.e., easy to read) and well-documented. In general, 75% of your grade for a program will be for correctness, 25% for "programming style" (appropriate use of language features [constants, loops, conditionals, etc.], including variable/procedure/class names), and documentation (descriptions of functions, general comments [problem description, solution approach], use of invariants, pre-and post conditions where appropriate). For this first assignment, correctness and programming style/documentation will each count for 50% of your grade.