Lab 1: Working with Pointers

Preliminaries

Before you begin this lab, you should read through the CS 361 Submission Procedures. Labs and projects that do not adhere to these procedures will not be graded. As such, it is important that you learn how to use Git in order to submit your code properly.

Make sure that you set up your configuration file correctly. Once you have done that, set up a bare repository and clone as described using the name lab1-ptrs.git for the repository.

Compiling, testing, and debugging pointers

For the first part of this lab, create a Git branch called fix-struct and implement the following three steps using that branch. When you are finished with these steps, merge that branch back into your main branch.

Step 1: Missing type declarations

The code provided does not compile, because the struct declared in movies.h is incomplete. Fix this by adding the necessary fields and their required types. Use the code in main.c (starting at line 37) to determine the types that are needed for each field. Once this struct is declared, there should be no compiler errors. Run make to confirm that the code compiles. (There should be warnings related to later parts of this lab.

Step 2: Testing failure

Once you've declared the struct fields, run make test to identify the failing unit tests. Start with the first failing unit test and look at the code for it in tests/public.c. Compare that code with the split_data() implementation in movies.c. Do not fix the code, but discuss why it might be failing.

Step 3: Tracing segmentation faults

Now run the program using ./ptrs -m. The code should have a segmentation fault when you do this. Determing where the fault occurs by starting a GDB session:

gdb --args ./ptrs -m
...
Reading symbols from ./ptrs...
(gdb)

At the first (gdb) prompt, run start to get to the beginning of main(), then continue to let it run. You'll then see a message that looks like the following:

Program received signal SIGSEGV, Segmentation fault.
__GI___strtok_r (s=0x5555555560f0 "The Shawshank Redemption,9.3,142,1994,Drama,true", delim=0x555555556196 ",", 
    save_ptr=0x7ffff7fafca8 ) at strtok_r.c:72
72	strtok_r.c: No such file or directory.
(gdb)

Now run the backtrace command and determine which line of movies.c caused the segmentation fault. This line is the cause of the test failure in Step 2. Use quit to get out of GDB, then fix this code. (HINT: Notice that the next line uses strdup(). What does this function do and how does that relate to this current bug?)

Once you think you have fixed the code, run make (not make test) to recompile the code and run the executable again as ./ptrs -m. If your fix is successful, you should not have a segmentation fault and you should see the title printed out. Once that is true, run make test to confirm the unit test now passes.

String manipulations

Many of the biggest headaches with pointers relate to improper manipulation of string pointers. C strings are very different from Java strings, which can lead to common mistakes. These steps illustrate how to work with strings in a way that C understands. Implement these two steps on a new branch called strings, merging the completed work back into main.

Step 4: String parsing

Finish the rest of the split_data(), adding just enough code to pass the associated unit test cases. Use the comments in split_data() (in movies.c) to store the information from each token (created by splitting the string at each ",") into the movie. See how movie.title is set up for an example. Also refer to the OpenCSF Appendix for more examples of strtok().

Again, do not rely on make test for debugging. Recompile and run the code manually, convincing yourself the code is functioning correctly. Once you are sure, then run make test and (if successful) add a Git commit.

Step 5: String merging

The UNIT_merge_movie and INTEG_movies tests should be failing at this point. Examine the expected integration test output (in tests/expected/INTEG_movies.txt) and compare it with the output your code produces. Add just enough code to merge_data() append the title, then compile and rerun the program. If the title is being printed on the last line of output, complete the function.

Memory leaks and submission

Step 6: Memory leaks (optional but recommended)

If you followed the instructions above exactly (without doing more than told to), you introduced a memory leak in Step 3. However, the scripts run by make test don't actually detect this one, because it is marked as "possibly" lost instead of "definintely" lost. To identify and fix this leak, run valgrind --leak-check=full ./ptrs -m. Where is there a memory leak? What causes it and how can you fix it?

Fixing memory leaks is not required for labs, but it is required for project submissions. This step will give you practice fixing them.

Code submission

As you completed these steps, you should have created multiple Git commits using git add and git commit. To submit your code for grading, run the git push command. If you want to confirm that your code has been submitted, create a new clone somewhere else in your $HOME directory. This clone will have any code that you pushed to your repository.