This homework will be worth a total of 65 points.
There will be an autograder, AND a manual-grading part for this homework. You are encouraged to resubmit until you earn a higher score on the auto-grading part before the due date. However, we will only do manual grading once, after the late period is over.
Auto-grading part (58 points)¶
Warning
You should not use this autograder as your primary test mechanism, but it will provide some immediate feedback. In fact, your submissions will be rate-limited so that you can only submit to the autograder 5 times every hour. This is to help encourage you to test locally (with the tests you wrote in HW5) before relying on the autograder!
-
You must write a
Makefile
which compiles your library. Your code must compile and run without errors or warnings when compiled with yourMakefile
oncalgary
. YourMakefile
must invokegcc
with the-Wall
and-std=c11
options. -
You should test for correct behaviors when running
./t9_demo
with different dictionaries oncalgary
. Read throught9_lib.h
and make sure you test with various inputs. -
Your library should exhibit no memory leaks or other memory errors when the demo program is run using
valgrind
. -
You should check your code with
clint.py
and ensure there are no style errors. Specifically, you should remove all the TODOs once you finish implementing T9.
Manual-grading part (7 points)¶
-
At the top of the file, include a header comment containing your name, the date of code creation, and a concise description of the program’s functionality.
-
Include descriptive comments throughout your code to explain the purpose and functionality of different sections. Comments should provide clarity and aid understanding for others.
-
Use good style, including helper functions and naming conventions. Make sure you declare your functions (prototypes) that are not in the header files before defining or using them in the code.
-
No global variables. Use parameters (particularly pointers) appropriately. Global constants are okay, however.
-
Avoid making excessive copies of large data structures. Consider using pointers instead.
-
If you need to create a copy of a string or other variable-size data, you should dynamically allocate an appropriate amount of storage using
malloc
and release the storage withfree
when you are done with it. The amount allocated should be based on the actual size needed, not some arbitrary size that is assumed to be “large enough”. -
You must check the return status (result code) of every library function you call to be sure that no errors occurred. In particular,
malloc
will returnNULL
if it is unable to allocate storage. Although this is extremely unlikely to happen, a robust program must check for the possibility and react appropriately if it does.