CSE 333 Exercise 3

Out:   Monday, January 12
Due:   Wednesday, January 14 by 11 AM
Rating:   2 (note)
CSE 333 Exercise Rating Scale

Each exercise this quarter is rated on a integer scale of 1 – 5, inclusive, with 1 being the "least time-consuming" and 5 being the "most time-consuming".

This difficulty scale is meant as a rough guide for you in predicting the amount of time to set aside for each exercise as you balance the work required for 333 with your other obligations. However, it is necessarily imperfect as everyone's set of circumstances and experiences with the exercises differ. If your experience with an exercise does not align with its rating, that is not a reflection of you or your abilities.

Goals

  • Define and use structs with typedef.
  • Use malloc and free to manage dynamically-allocated data without memory leaks.
  • Write some basic automated tests in C.

Problem Description

Your job is to write a C program that does the following:

  • Uses typedef to define a new structured type called Point3d, which contains int32_t fields for x, y, and z coordinates.
    • This means you should be able to refer to the struct with the following syntax: Point3d p = ...;
    • For the sake of the autograder, do not use typedef to define pointers to Point3d structs to be Point3dPtr; instead, use Point3d*.
  • Defines a function called AllocatePoint3d that (1) accepts three int32_t arguments, (2) malloc's space for a Point3d, (3) assigns the three arguments to the x, y, and z fields, and (4) returns (a pointer to) the malloc'ed Point3d.
  • Has a main function that runs at least one automated test on AllocatePoint3d. Make sure to read the relevant portion of the Implementation Notes below ("Testing") very carefully to make sure that you understand what this is asking for.
    • For the purposes of this exercise, it is enough for you to write code that simply allocates a struct by calling AllocatePoint3d and verifies that the struct members contain the correct values.

Implementation Notes

Error Handling & Robustness

As part of this exercise, you will have to make design decisions about how to handle errors. Be sure to handle errors, including malloc failures. Whatever decisions you make, be sure to document them appropriately.

Memory Cleanup

Make sure your main frees any memory that was dynamically allocated, even when handling edge cases. We will be using valgrind (valgrind --leak-check=full ./ex3) to check for memory leaks and other memory issues.

Testing

When writing your tests, don't make assumptions about what the tested function does, even if you implemented it. Imagine that you are testing an implementation written by another programmer.

  • If your test(s) pass, your program should terminate silently (i.e., don't print a "success" or "all tests passed" message).
  • When an error is encountered during testing, you should immediately return an appropriate status code to indicate failure in addition to printing an error message. This signals an error to the parent process (this is what makes it automated) and is easier to detect than having to manually scan over your program output, especially if you have a lot of tests in the future.

main is considered testing code. Testing code is the only place where the use of assert() is allowed, though you do not need to use it at all if you don't want to.

Style Focus

General

Make sure that your function and type names match the specifications exactly, including capitalization. You should write comments explaining the behaviour and purpose of the struct and functions you define. Be sure that the comments you write document how errors are handled.

Typedef

This is supposed to make your life easier! Make sure that your syntax is correct and that you're taking advantage of the new alias.

Error Handling & Robustness

Are there any problematic arguments or special return values to look out for in library functions that you are using or functions that you have written? Which stream should error messages go to?

Submission

Submit the following file(s) by creating an ex3-submit tag in your exercise repo before the assignment deadline. The file(s) should be located in the exact directory listed below, including capitalization:

  • ex3/ex3.c

Your code must:

  • Compile without errors or warnings on CSE Linux machines (lab workstations, attu, or CSE home VM).
  • Have no runtime errors, memory leaks, or memory errors (gcc and valgrind).
  • Be contained in the file listed above that compiles with the command: 
    $ gcc -Wall -g -std=c17 -o ex3 ex3.c
  • Have a comment at the top of your .c file with your name(s) and CSE or UW email address(es).
  • Be pretty: the formatting, variable and function names, commenting, and so on should be consistent with class style guidelines.
  • Be robust: your code should deal with hard-to-handle/edge cases and bogus user input (if there are any) gracefully.