Lab 2

Goals

Further review C programming topics.
Practice with Unix library calls.
Develop skills to read and correctly interpret Unix manual pages.

Credits

This lab was developed by Prof. L. Felipe Perrone. Permission to reuse this material in parts or in its entirety is granted provided that this credits note is not removed. Additional students files associated with this lab, as well as any existing solutions can be provided upon request by e-mail to: perrone[at]bucknell[dot]edu

Academic Responsibility

It should go without saying that all the work that you will turn in for this lab will be yours. You should try your best to debug your code on your own, but it’s fine to get help from a colleague as long as that means getting assistance to identify the problem and doesn’t go as far as receiving source code to fix it (in writing or orally).

Do not surf the web to get inspiration for this assignment and do not include code that was not written by you. One exception will be allowed: if you have not completed last week’s assignment, you can opt to have a solution for it generated by AI. The constraint is that the solution must adhere to the interface (API) specified for the slist functions in the previous assignment. (Note: it may be quicker to complete that part yourself!)

Set Up

Before you start, do the following on a terminal:

cd ~/csci307/Labs/Lab2
cp ~perrone/csci307/Labs/Lab2/* .

Context

In this assignment, you will start building up a flight reservation system, similar to what airline companies might have used in the past. This system will use three letter codes to identify airports, such as, YYZ for Toronto’s Pearson Airport, Ontario, Canada, or MDT for Harrisburg, Pennsylvania. A Makefile is provided to you as a starting point – note that you will need to extend it for additional modules or programs you create.

Problem 1

Read the files flight.h and flight.c to find skeleton code for a module that defines a data structure to hold flights and functions to manipulate this structured data type. Your first task is to complete the two functions described below. A file called flighttest.c to test the functions is provided for you. It is your responsibility to make sure that this file compiles and works correctly.

1) time_t flight_time(int minute, int hour, int day, int month, int year);

This function takes in arguments for a full calendar date as integers and converts the date into data type time_t representing Unix time (seconds elapsed since January 1, 1970). Read the manual page for the library function mktime(3), which you will need for this task.

2) int flight_compare(struct flight* f1, struct flight* f2);

Comparing two instances of a structured data type in C requires more work than just using the equality operator (==) in the test of an if statement. Since struct flight contains pointers to data (remember the duality between arrays and pointers?), you will need to use the library function memcmp(3) to compare fields one by one.

After you debug your code and get everything working correctly, add, commit and push your files to your gitlab as follows:

git add flight.h
git add flight.c
git add flighttest.c
git commit -m "lab2-1 completed" 
git push

Problem 2

Read the files reservation.h and reservation.c to find skeleton code for a module that defines a data structure to hold reservations and functions to manipulate this structured data type. Your first task is to complete the three functions described below. A file called reservationtest.c to test the functions is provided for you. It is your responsibility to make sure that this file compiles and works correctly. (Hint: it has compilation errors.)

1) void reservation_init();

If you carefully read the code provided in file reservation.h, you will note that this module defines a pointer to singly linked list using the data structure struct slist you developed last time. This function must initialize this pointer with the address of an instance of an empty struct slist. Yes, that’s all this function should do.

2) int reservation_compare(struct reservation *r1, struct reservation *r2);

This function is similar to flight_compare in the sense that it will need to use memcmp(3) to do a “deep comparison” of the fields in the two instances provided by the caller. However, it should compare all the fields of the two struct reservation instances reached by the provided pointers except for their id fields. This means, we will consider two reservations to be identical if they have different values in their id fields but the same content in other fields. The function should return 0 if the two structures have identical values and different ids, otherwise it should return 1.

3) int reservation_add(struct reservation *r, uint32_t id, char *name, struct flight *f);

This function takes in a pointer to a struct reservation, initializes with the caller provided values, and inserts it into the list pointed by struct slist reservation. Because we don’t want the list to contain identical copies of the same reservation, you must make sure to verify that no reservation already in the list contains the same values given by the caller. This means, you need to traverse all the nodes in the list pointed by struct slist reservation comparing them to the new reservation the caller is trying to create. If you determine that no identical reservation exists, return 0, otherwise return 1.

Here is an important detail: this module defines an integer uint32_t reservation_id that will grow monotonically with each reservation added to the system. This integer will provide a unique identifier to each reservation. If a call to this function indeed defines a new reservation (nothing identical already exists), the function must first increment id and then assign it to the new reservation. If you think about this for a minute, you will realize that reservation_id needs to be initialized with 0 somewhere. What is the most natural place in this module to accomplish this?