The commands for perusing data records sequentially — NEXT and PREVIOUS — both ignore inactive records. The LIST command, however, lists all records in the database, both active and inactive. To access an inactive record, the SELECT command may be used to address the record directly via the record number shown by the LIST command. Once an inactive record has been SELECTed, the UNDELETE command may be used to make the record active once again, if desired.

Inactive records only "stay around" until the next time the FIX command is invoked. Each time FIX is run, the storage for all deleted records is freed and the record pointers are compacted and sorted.

Upon entry to edit_db(), cur_rec is initialized to the first record of the database and an infinite loop is begun. For each iteration of the loop, rp is set to point to the new current record's data, and the values of all fields in the current record are displayed on the console output. If there are currently no records in the database (determined by checking the value of n_recs for 0), then the current record display sequence is skipped.

Next, the menu is displayed and the user selects from the list of editing options. The options are:

Once storage is acquired, cur_rec is set to the old value of n_recs (the record count) and n_recs is incremented to reflect the new number of records (line 125). After this operation, cur_rec is the subscript of the slot in RECS that will hold the new record pointer. Next, rp is copied into the new slot (line 126) and the element active is made TRUE (line 127). In lines 129 though 134, all data elements of the new record are initialized to "empty" values and control falls through to the next case, MODIFY.

• The record description and current value is displayed.
• A line of input text is read from the console.
• If the line is empty (i.e., if the Return key was pressed immediately), then the original value of the element is left intact.
• Otherwise, the value of the element is overwritten with the value of the input (converted to the appropriate data type).

while (strlen(gets(buf)) > 0 /* if not empty line */
{
    char c = toupper(*buf);
    if (!(c == 'M' || c == 'F')) /* if not legal */
    {
        printf("Please enter 'M' or 'F': ");
        continue; /* ask again */
    }
    rp->gender = c; /* assign the value */
    break; /* exit the loop */
}

To purge deleted records, a single pass is made over the database records using two indices. The first index, the loop variable i, iterates over the entire array of record pointers (that is, all n_recs records). The second index, new_n_recs, is incremented only for active records; when an inactive record is encountered, new_n__recs is not incremented, and the pointer to the inactive record's data is passed to the free() function to deallocate the storage.

At the start of each iteration through the loop, record i is copied into position new_n_recs (line 222), and then new_n_recs is adjusted as described. The result is that the memory used by all inactive records is de-allocated, and the positions in the RECS array formerly occupied by inactive record pointers are filled in with active pointers.

After the purge loop completes, a single call to the qsort() library function sorts the remaining records. qsort() is a wonderfully versatile function, but the interface can be a bit confusing. In this case, we wish to sort the pointers in the RECS array by the last field; we first set up the call to qsort() and then set up a comparison function that qsort() uses to determine the relationship between two pointers.

qsort() takes four parameters: a pointer to an array of data items to be sorted, the number of items in the array, the size of each item, and a pointer to a user-supplied function (to be called by qsort() directly) that accepts two pointers to the data array elements as parameters, compares the two data items specified by the pointers, and returns (to qsort() one of several pre-defined values indicating the relative ordering of those two data items.

Since we are sorting the pointers in the RECS array, we pass RECS as the first parameter. The number of items in the array is new_n_recs (as a result of the purge loop just completed.) As we are sorting pointers, we pass the expression

sizeof(struct record *)

The comparison function, as described above, must be designed to accept parameters that are pointers to the data type being sorted. Since the data we are sorting have type "pointer to structure", the parameters to the comparison function must be of type "pointer to pointer to structure." For a return value, the comparison function must return either zero (if the data items are equivalent, using whatever arbitrary ordering rules we wish to apply), a negative value (if the first item is "less than" the second by those same rules), or a positive value (if the first item is "greater than" the second.) The function header (line 242) reflects these specifications.

Notice that a prototype for the compar() function is given (line 214) so that the identifier compar is recognized as a function having the proper characteristics when fix_db() calls qsort() (line 230). Alternatively, the entire definition of compar() could have been placed where the prototype is now located, eliminating any need for the separate prototype. I prefer to list functions in top-down order, however, so the prototype becommes necessary.

The body of the compar() function compares the element last (a string representing the last name of the person described in the record) from both records using the strcmp() standard library function. strcmp() is ideally suited for use with qsort(), because its return value is defined exactly as specified for the qsort() comparison function. The tricky part of compar() is remembering to de-reference the "structure pointer pointer" parameters in order to use them as simple "structure pointers" (line 245.) Note the need for parentheses around the indirection sub-expression of each parameter to strcmp(); without the parentheses, the selection operator (->) would take precedence over the indirection operator (*) and draw a compiler error.

I'll devote future installments to showing some different approaches to implement read_db() and write_db(). As a challenging exercise, see if you can come up with a scheme for implementing these functions on your own. Would you save the data on disk in the form of ASCII text or binary data? Which library functions would you use in each case? What would be the advantages of ASCII over binary, or vice versa?

For a smaller-scale exercise, see if you can develop a replacement for the do_menu() function that has a slicker user interface. For example, you might include the ability to specify commands by a highlighted letter within the text of the command, as well as by a sequential number. Part of the menu specification would then have to include information about which letter to highlight — perhaps by including a "magic" character in the menu item text that flags the subsequent character as special. Or, you may choose to adapt a windowing menu routine from some general C library function package.