Laboratory Exercise 2

Description

Problems

These problems are designed to provoke some thought (could there be a quiz coming?):

1. (Warm up) Please provide declarations for the following data:

1. • a pointer cp that points to a char.

1. • a pointer ap that points to an array of chars.

1. • a pointer pp that points to a pointer that points to an int.

2. Is it possible in C to declare and initialize a pointer that points to itself? Why or why not? (And, if so, how, of course.)

3. What is the fundamental problem with the following code fragment intended to print out a string:

char s[] = “Hello, world!\n”;

char *p;

for(p = s; p != ’\0’; p++) {

putchar(*p);

}

What will happen when this is executed? How can it be fixed?

4. C programmers often say “arrays are the same as pointers”. In one sense this is true. In another, more correct, sense they are fundamentally different.

   • In what ways is this statement correct?

4. • How is it in error? That is, what makes a pointer fundamentally different from an array?

5. List the three flaws you discover in part 1 of the laboratory exercise. (See below.)

5. Exercise 1.3 from Stevens APUE.

5. Exercise 1.5 from Stevens APUE.

5. A subcase of Ex. 2.2 from Stevens: On unix4, what is the actual data type of a size_t (the type of malloc()’s argument)? In what header file is it defined?

Figure 1: http://xkcd.com/371/

Laboratory Exercises

1. GDB Tutorial.

Read and understand the Quick Introduction to GDB linked from the main web page.

Once you have done this, write a small program, compile it, and run it within gdb. At the very least, you should:

1. 1. set a breakpoint by function name,

1. 2. print the value of some variable in the function,

1. 3. examine a backtrace to see how the function was called, and

1. 4. step through a loop.

Once you have done all those things, download a copy of labprog.c and figure out what’s wrong with it. It is available on the course website with this lab.

There are 3 significant flaws in it I expect you to note.

You could probably figure these out by hand, but use the debugger. It’s an important tool.

2. Learn to use make(1)

make(1) is a wonderful build-management tool that will help you keep your programs up to date while minimizing compile time by only recompiling

those components for which it is necessary. Besides, there is a direct benefit to this because every assignment from here on out will require you to submit a functional Makefile.

Your task:

1. Read the Quick notes on make from the lab webpage

2. Read and study the sample makefiles published with the solutions to Asgn1, also linked from the cpe357 page.

3. Write a small program consisting of at least two separate source files and create a Makefile for it. This makefile must compile the program when no argument is given to make, and support the following targets:

1. • all – Build the program

1. • prog – (where prog is whatever your program is called) Build the program.

   • test – Builds the program and runs it with a sample input. (For example, if the program reads a string and reverses it, make test could execute a command like echo “hello” | myprog)

1. • clean – Removes all non-essential files generated during the build.

Generally this means the intermediate object (.o) files.

Your goals when writing this makefile should be to minimize the amount of duplication. That is, all, prog, and test should not each have separate instructions for building the program. You should also make sure to include appropriate dependency information so that if one of your source files changes make will only recompile those files that need to be recompiled. When finished: Write me a few sentences about the approach you took, problems you encountered, and lessons you learned and attach them, along with a printout of your makefile, to your written exercises above.

3. Program: uniq

This program is an exercise with dynamic data structures as a warm-up for Assignment 2.

Write a version of the unix utility program uniq(1). This program will act as a filter, removing adjacent duplicate lines as it copies its stdin to its stdout. That is, any line that is identical to the previous line will be discarded rather than copied to stdout.

Your program may not impose any limits on file size or line length. To get started, I highly recommend writing a function

char *read_long_line(FILE *file)

that will read an arbitrarily long line from the given file into newly-allocated space. Once you have that, the rest of the program falls into place.

Be careful to free memory once you are done with it. A memory leak could be a real problem for a program like this.

Tricks and Tools

There are some library routines with which you might want to be familiar before attacking labprog.c listed below.

strlen(3)	calculate the length of a string
strcmp(3)	compare two strings
fgets(3)	read a string into a buffer
malloc(3)	allocate a given number of bytes of memory from the heap
realloc(3)	Change the size of a previously allocated chunk of memory
free(3)	return a malloc()ed region of memory to the heap

What to Turn In

Submit via handin to the lab02 directory of the ngonella account:

• your well-documented source file(s) for uniq

• A makefile (called Makefile) that will build uniq from your source when invoked either with no target or with the target “uniq”.

• A plaintext document answering the written problems

4