Timed Lab 4: C Solution

    •  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).

    2. Although you may ask TAs for clari cation via Piazza as a private post, you are ultimately respon-sible for what you submit. The information provided in this Timed Lab document takes precedence. If in doubt, please make sure to indicate any con icting information to your TAs.

    3. You are strictly prohibited from collaborating or communicating with any other person about Timed Lab 4 or any materials deemed to be related to Timed Lab 4. If any collaboration of any kind is detected, you will receive a 0 on the assignment and may be reported to the O ce of Student Integrity.

    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 les, what you turn in is what we grade. In addition, your assignment must be turned in via Gradescope.

    3. Do not submit links to les. We will not grade assignments submitted this way as it is easy to change the les after the submission period ends.

1.3    Is collaboration allowed?

To reiterate, absolutely NOT. No collaboration is allowed for timed labs.


    • 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    rst 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 dynamically-allocated memory associated with it.








2
    • Instructions

You have been given one C le - tl4.c - in which you should complete the deep copy() and destroy() functions according to the comments.


You should not modify any other les. Doing so may result in point deductions. You should also not modify the #include statements, nor add any more. You are also not allowed to add any global variables.

3.1    Writing deep copy()


The function deep copy() 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


struct node *head


struct list





struct node *next





3



"Cubone"


char *name






struct node















struct node *next






2



"Marowak"


char *name
Deep Copy:





struct node















NULL

struct list *listToReturn



struct node *head






struct list



















struct node *next






3



"Cubone"



char *name







struct node

















struct node *next







2



"Marowak"


char *name








struct node
















NULL



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


3

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.


    • Debugging with GDB - List of Commands

Debug a speci c test: make run-gdb TEST=test name


Basic Commands:

b functionbreak point at a speci c function

r    run your code (be sure to set a break point  rst)

n    step over code

s    step into code

p/x variableprint variable in current scope in hexadecimal

bt    back trace displays the stack trace










































4
    • 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 Make le.

Note: There is a le called test utils.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 le as you will need to redownload the assignment. Also keep in mind that this le 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 rst! 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 Make le section, as well as how to run it on all of your tests.

The given test cases are the same as the ones on Gradescope. Your grade on Gradescope may not necessarily be your nal grade as we reserve the right to adjust the weighting. However, if you pass all the tests and have no memory leaks according to valgrind, you can rest assured that you will get 100 as long as you did not cheat or hard code in values.

You will not receive credit for any tests you pass where valgrind detects memory leaks or memory errors. Gradescope will run valgrind on your submission, but you may also run the tester locally with valgrind for ease of use.

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 in nitely, 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 Make le section for running an individual test with gdb.

5.2    Make le

We have provided a Make le for this timed lab that will build your project.

Here are the commands you should be using with this Make le:

    1. To clean your working directory (use this command instead of manually deleting the .o les): 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 speci c test with valgrind: make run-valgrind TEST=test name

    5. To debug a speci c test using gdb: make run-gdb TEST=test name Then, at the (gdb) prompt:


5

    (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/list suite.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 test list deep copy basic easy:


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 speci c test using gdb" instructions above.

Note: The checker may not re ect your actual grade on this assignment. We reserve the right to update the checker as we see t when grading.


    • Deliverables

Please upload the following    les to Gradescope:

1. tl4.c

Your le must compile with our Make le, which means it must compile with the following gcc ags:

-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 man-ually; use the Make le as described below.

Download and test your submission to make sure you submitted the right    les!





















6