Introduction
src，
Curtin University — Department of Computing
UNIX and C Programming (COMP1000)
Semester 2, 2017
Assignment
Due: Friday 27 October, 9:00 am Weight:
20% of the unit mark.
Your task for this assignment is to create, in C, a stand-alone spell-checker program.
Your program will take three input files: a text file to check (the “user file”), a dictionary file
containing correct spellings, and a settings file. The words in the user file will be spell-checked,
and any resulting corrections written back to that file.
Part of the program has already been written; you must develop the rest of the program around
the existing code.
1 Documentation
You must thoroughly document your code using C comments (/ … /).
For each function you define and each datatype you declare (e.g. using struct or typedef), place a
comment immediately above it explaining its purpose, how it works, and how it relates to other
functions and types. Collectively, these comments should explain your design. (They are worth
substantial marks – see Section 7.)
2 Program Outline
Your program must do the following:
a) accept one command-line parameter: the name of the user file to be checked. Invalid
command line arguments should cause the program to output a usage message, and exit.
b) read the settings file .spellconf and store its contents in a struct. The format of the
settings file is described in Section 2.1.
c) read the dictionary file specified inside the settings file, placing each dictionary word into a
linked list. The dictionary file contains one word per line. Once the whole dictionary file
has been read, your program should copy the contents of the linked list to a dynamically
allocated array.
d) read the user file in the same fashion. For the sake of simplicity, assume that the file
consists entirely of words separated by whitespace
e) call the pre-existing function check() , providing a callback (function pointer). The
check() function is described in Section 2.2, and the callback function in Section 2.3.
f) Once the check() function has finished, your program should write the user file array
back to the user file. You do not need to preserve the original formatting
2.1 The settings file
The settings file must be called .spellconf
Each line in the file contains a name, then “=”, then a value (separated by whitespace). The
allowed setting names are: dictfile, maxdifference and autocorrect . These
settings may appear in any order, be repeated or be omitted. You must decide how to handle
these situations.
For dictfile , the value is the name of the dictionary file.
For maxdifference , the value is an integer representing the maximum allowable difference
between a misspelt word and any corrections to be found. This is the “edit distance” between two
words — the number of single-character changes it takes to transform. one word into another.
For autocorrect , the value is either yes or no , indicating whether your program should
automatically apply any corrections found, or ask the user first.
Your program should store these settings in a struct for later use.
2.2 The check() function
The check() function, provided in check.h and check.o , is defined as follows:
void check(char text[],
int textLength,
char dict[],
int dictLength,
int maxDifference,
ActionFunc action)
Your program must use this function to perform. the actual spell-checking.
The parameters are as follows:
text — an array of words to spell check (each word must be dynamically allocated);
textLength — the number of words to spell check;
dict — an array of words to use as the dictionary;
dictLength — the number of dictionary words;
maxDifference — the maximum difference between misspelt words and their
suggested corrections;
action — a pointer to a function that will be called for each misspelt word.
The check() function checks the spelling of each word in text against the dictionary words in
dict. If no exact match is found, it tries to find the closest matching word.
The maxDifference parameter should be set according to the maxDifference value from
the settings file.
2.3 The ActionFunc pointer
The check() function takes a function pointer of type ActionFunc , defined as follows:
typedef int (ActionFunc)(char word, char* suggestion);
You must write one or more functions matching this definition, and supply one to the check()
function.
Your callback function will receive two parameters:
word — a misspelt word;
suggestion — a suggested correction, which could be NULL if the word is too badly
misspelt.
Your callback function must make a decision on whether to accept the suggested correction or
not. It should return TRUE if the correction is to be accepted (and the original word modified) or
FALSE if the misspelling should be ignored.
This decision will be based on the autocorrect value from the settings file. If autocorrect is yes,
then all words that can be corrected should be. Otherwise, the user should be presented with the
original word and the corrected version, and asked to choose between them.
If suggestion is NULL, no correction is possible, irrespective of the autocorrect setting.
3 Makefile (or “How to Actually Get Marks, part 1”)
You must create a makefile, and it must actually work. That is, the marker will type:
[user@dir]$ make
This is the only way the marker will attempt to compile your code. If your makefile does not work,
then, according to the marking guide, your code does not compile or run. (The marker will delete
all existing .o files and executable files beforehand.)
Your Makefile must be written by you, and not automatically generated. It must be structured
properly in accordance with the lecture notes.
4 Testing (or “How to Actually Get Marks, part 2”)
Your program must work on the lab machines in building 314.
To begin with, construct a small-scale test file containing only a few columns and lines. As you
begin to fix bugs, try larger test files. You will find a full-scale dictionary file in the directory
/usr/share/dict/ .
All user input must be “sanity” checked. Invalid user input should not cause the program to stop
(other than invalid command line arguments).
Ensure there are no memory leaks - you must not rely on the program closing to free your
memory. You will lose marks for any memory issues.
5 README.txt
Prepare a text file called README.txt (not using Word or any other word processor), that
contains the following:
• A list of all files you’re submitting and their purpose.
• A statement of how much of the assignment you completed; specifically:
– How much of the required functionality you attempted to get working, and
– How much actually does work, to the best of your knowledge.
• A list of any bugs or defects you know about, if any.
6 Submission
You must also submit the following electronically, via the assignment area on Moodle, inside a
single .tar.gz file:
• Your makefile and README.txt.
• All .c and .h files (everything needed for the make command to work).
You are responsible for ensuring that your submission is correct and not corrupted (download
and check it!). You may make multiple submissions, but only your newest submission will be
marked.
7 Mark Allocation
Every valid assignment will be initially awarded 100 marks. Marks will then be deducted for the
following:
up to -50% Commenting.
You will not lose any marks if you have provided good, meaningful explanations of all the files,
functions and data structures needed for your implementation.
up to -50% Coding practices
You will not lose any marks if you have followed good coding practices, and your code is
wellstructured, including being separated into various, appropriate .c and .h files.
up to -100% functionality.
You will not lose any marks if you have correctly implemented the required functionality,
according to a visual inspection of your code by the marker.
up to -100% working product.
You will not lose any marks if your program compiles, runs and performs the required tasks
without unexpected error. The marker will use test data, representative of all likely scenarios, to
verify this. You will not have access to the marker’s test data.
You may also lose this entire component of your mark by either (a) not having a working
makefile, OR (b) failing to solve memory issues.
Once your mark has been calculated, the practical signoff result will be applied as follows:
Your total practical workshop submissions will be awarded a mark out of 9, which will have the
following effect on the assignment mark.
Total Effect
7 - 9 100
6 90
5 80
4 70
3 50
0 - 2 30
End of Assignment