To be completed before your lab period. Print out the questions and hand them to your TA when you arrive at lab. These will only be accepted up until 5 minutes after the advertised start of your lab. This is how you get attendance credit for lab.

Goals for this Pre-Lab

  • Familiarize you with the C development cycle
  • Familiarize you with the code we will be using in the warmup.

prelab questions - make sure you answer them, print it out, and hand it to your TA at the beginning of lab.

Overview

If you have never programmed in C, then this overview is for you. Programming in C has several differences from Racket, Java, and other languages, though it's more similar to Java than Racket. For the rest of this overview, I am going to assume Racket is your only prior experience.

You are used to an interactive programming environment. You can type in a little code, then test it, then type in some more, test it, etc. You're able to make modifications just by typing in the code again. You immediately are able to use that new code. This provides a nice environment for beginners, but it does not produce efficient code for the end user. This quarter, you are learning C, which is a language created for efficiency, not programmer ease.

When type your program, you type it into a file and edit it there. This file needs to be stored on the computer, just like a word document or some other file. It can't be a word document, however, because Word introduces formatting information. The file must be a plain text file with just the letters and carriage returns. The computer does not understand this file - it needs to be translated (and optimized) into machine code that the machine can run. In Dr. Racket, the computer wasn't actually running the code directly. Instead, Dr. Racket read in the code and told the computer what to do. That's why it's so inefficient. Every time you make changes, make sure you save the changes before moving on compilation.

The next step is to compile the code into an executable that the computer can run. We won't do this from within the text editor. You may either exit the editor and run from the command line or open a second window that you can use to compile and run the program. I strongly suggest the latter. The compiler we'll be using is clang. It is a free compiler that gives more helpful information than its predecessor, gcc. The default name of the executable is a.out in the directory where you called the compiler.

Finally, you can run the program. You do so by typing "./a.out"

Repeat this process until you have completed and tested all of the code!

Set up

In order for me to get to know you, you need to fill out the Student Info Form.

Example Code

During lab, in order to practice editing and compiling, we are providing you a complete program, split into three important files. Go through each file, with the associated explanation, to get ready for lab.

Begin by reading through functions.c.

This code has been chosen especially to introduce you to not only the syntax and semantics of C, but also norms we will expect in this class. Take note of:

  • The types in the input parameters and return values
  • What to do when erroneous input is received
  • Explanatory comment for each function
  • Inline comments for the useful function
  • Proper indentation
  • Examples of using printf with different types and different configurations

  • The return type unsigned long int is a nonnegative integer that is also "long" (that is, has a larger maximum value than a plain "int"). We will talk much more about this and other type distinctions in the coming weeks.
  • The argument type unsigned int is nonnegative. This is desirable in the present case since we don't have a definition of factorial on negative inputs anyway.
  • Note that C is entirely permissive when it comes to spacing and line breaks. Nevertheless, please follow the spacing and indentation conventions you see on this page and in K&R (that is, The C Programming Language, Second Edition by Kernighan and Ritchie). If there is ever any doubt about how to format code, we refer to K&R's body of examples as the authority.

Testing Methodology

There are several general principles we will follow for testing.
1. Place your main in a separate file from your implementation so that you can swap out the main easily.
2. Create a set of test cases for each function that exercise the code well.
3. Create one test function for each function you're testing that takes in a single test case and tests it.
We'll illustrate those three principles below.
Principle 1: Place the main in a separate file.

Now that you have code written, you need to test it. This requires a main file. All C programs begin in main. We are going to place this main function in a different file so that we can easily swap out what code is calling this function. The main function has been placed in main.c.

Principle 2 and 3: Testing Look at explanations for Principles 2 and 3 within main.c.

Now we need a way to connect main.c and functions.c. That is, when the compiler is looking at main.c, we need to be able to tell it what the functions are in functions.c that it can use. A header file is necessary to inform the code in main.c about what the function call names are, what the input arguments are, and what the return types are.

Whenever you call functions that are in one file from another file, you need a header file or .h file. We have provided this file: functions.h. You need the prototype of each function in the x.h file that any code outside of x.c will use, along with a comment stating the purpose.

Checklist

Don't forget:
If you have extra time, you can get a head start by running vimtutor. This takes about 30 minutes, and it will familiarize you with an editor we will use this quarter.