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.

You must write a Makefile which compiles your library. Your code must compile and run without errors or warnings when compiled with your Makefile on seaside. Your Makefile must invoke gcc with the -Wall and -std=c11 options.

You should test for correct behaviors when running ./t9_demo with different dictionaries on Seaside. Read through t9_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 with free 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 return NULL 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.