CS 2110 Timed Lab 4: C Solution

Please take the time to read the entire document before starting the assignment. It is your responsibility to follow the instructions and rules.
1 Timed Lab Rules - Please Read
1.1 General Rules
1. You are permitted to submit the timed lab at any time prior to 11:59 pm EDT (Eastern Daylight Time).
4. We reserve the right to monitor your computer during the 24-hour Timed Lab period using cameras, packet capture software, and other means.
1.2 Submission Rules
1. Follow the guidelines under the Deliverables section.
2. You are also responsible for ensuring that what you turned in is what you meant to turn in. After submitting you should be sure to download your submission into a brand new folder and test if it works. No excuses if you submit the wrong files, what you turn in is what we grade. In addition, your assignment must be turned in via Gradescope.
3. Do not submit links to files. We will not grade assignments submitted this way as it is easy to change the files after the submission period ends.
1.3 Is collaboration allowed?
To reiterate, absolutely NOT. No collaboration is allowed for timed labs.
2 Overview
2.1 Description
In this timed lab, you’ll be writing two functions which will act on a singly linked list of pokemon structs. The first of these, deep copy(), performs a deep copy on a list.
The second function, destroy(), takes a pointer to a list and destroys the list, freeing all dynamicallyallocated memory associated with it.
3 Instructions
You have been given one C file - tl4.c - in which you should complete the deepcopy() and destroy() functions according to the comments.
3.1 Writing deepcopy()
The function deepcopy() takes in one argument, a pointer to List and returns a pointer to a newly allocated List. You should allocate memory for any nodes or elements of the node that are dynamically allocated. If the system cannot allocate enough memory to perform a deep copy, any allocations performed within the function should be freed, and NULL should be returned. There’s an example below:
Original:
struct list *listToCopy


Deep Copy: struct node
struct list *listToReturn


3.2 Writing destroy()
The function destroy() takes in one argument, a pointer to struct list, and does not return anything.
After this function executes, all dynamically allocated memory associated with listToDestroy must be freed. This includes any node structs in the list and their pokemon struct data, the list itself, and any other heap data referenced by any of these structs.
4 Debugging with GDB - List of Commands
Debug a specific test: make run-gdb TEST=test name
Basic Commands:
• b function break point at a specific function
• r run your code (be sure to set a break point first)
• n step over code
• s step into code
• p/x variable print variable in current scope in hexadecimal
• bt back trace displays the stack trace

5 Rubric and Grading
5.1 Autograder
We have provided you with a test suite to check your linked list that you can run locally on your very own personal computer. You can run these using the Makefile.
Note: There is a file called testutils.o that contains some functions that the test suite needs. We are not providing you the source code for this, so make sure not to accidentally delete this file as you will need to redownload the assignment. Also keep in mind that this file does not have debugging symbols so you will not be able to step into it with gdb (which will be discussed shortly).
Your process for doing this lab should be to write one function at a time and make sure all of the tests pass for that function—and if one of your functions depends on another, write the most simple one first! Then, you can make sure that you do not have any memory leaks using valgrind. It doesn’t pay to run valgrind on tests that you haven’t passed yet. Further down, there are instructions for running valgrind on an individual test under the Makefile section, as well as how to run it on all of your tests.
Printing out the contents of your structures can’t catch all logical and memory errors, which is why we also require you run your code through valgrind.
We certainly will be checking for memory leaks by using valgrind, so if you learn how to use it, you’ll catch any memory errors before we do.
Your code must not crash, run infinitely, nor generate memory leaks/errors.
Any test we run for which valgrind reports a memory leak or memory error will receive half or no credit(depending on the test).
If you need help with debugging, there is a C debugger called gdb that will help point out problems. See instructions in the Makefile section for running an individual test with gdb.
5.2 Makefile
We have provided a Makefile for this timed lab that will build your project. Here are the commands you should be using with this Makefile:
1. To clean your working directory (use this command instead of manually deleting the .o files): make clean
2. To run the tests without valgrind or gdb: make run-tests
3. To run your tests with valgrind: make run-valgrind
4. To debug a specific test with valgrind: make run-valgrind TEST=testname
5. To debug a specific test using gdb: make run-gdb TEST=testname
Then, at the (gdb) prompt:
(a) Set some breakpoints (if you need to — for stepping through your code you would, but you wouldn’t if you just want to see where your code is segfaulting) with b suites/listsuite.c:420, or b tl4.c:69, or wherever you want to set a breakpoint
(b) Run the test with run
(c) If you set breakpoints: you can step line-by-line (including into function calls) with s or step over function calls with n
(d) If your code segfaults, you can run bt to see a stack trace
To get an individual test name, you can look at the output produced by the tester. For example, the following failed test is testlistdeepcopybasiceasy:
suites/list_suite.c:50:F:test_list_deep_copy_basic_easy:test_list_deep_copy_basic_easy:0
ˆˆˆˆˆˆˆˆˆˆˆˆˆˆˆˆˆˆˆˆˆˆˆˆˆ
Beware that segfaulting tests will show the line number of the last test assertion made before the segfault, not the segfaulting line number itself. This is a limitation of the testing library we use. To see what line in your code (or in the tests) is segfaulting, follow the “To debug a specific test using gdb” instructions above.
6 Deliverables
Please upload the following files to Gradescope:
1. tl4.c
Your file must compile with our Makefile, which means it must compile with the following gcc flags:
-std=c99 -pedantic -Wall -Werror -Wextra -Wstrict-prototypes -Wold-style-definition
All non-compiling timed labs will receive a zero. If you want to avoid this, do not run gcc manually; use the Makefile as described below.
Download and test your submission to make sure you submitted the right files!