This phase concerns the implementation of an abstract data type to represent the C notion of type.
The first step is to read carefully the relevant sections of the 1989 ANSI C standard: 3.1.2.5, 3.1.2.6, 3.5.2, 3.5.3 and 3.5.4.
At the 60% level, you should design the interface for the abstract data type. The design should be presented as a well-documented header file named "type.h".
Your design should support the following functionality:
A struct/union type must be able to be constructed in two steps. First, the type is constructed. Second, the member list is added to the type.
The list mechanisms used for function parameter lists and struct/union member lists must allow the lists to be traversed from front to back and must must allow nodes to be appended to the list. If you wish, the details of these lists can be visible to the user (i.e. outside the black box).
Types can be qualified or unqualified. Array types and function types are always unqualified. Other types can be qualified as either const-qualified, volatile-qualified, or const-volatile-qualified. Therefore the type constructors must include the ability to build both qualified and unqualified types. In addition you should include functionality to query whether a type is qualified or not and, if so, how it is qualified. Finally, you also need to include functionality to construct the unqualified version of a type and functionality to check for two types that are "qualified or unqualified versions of compatible types" if one type "has all the qualifiers of the [other] type" (ANSI C: 3.3.16.1).
Struct/union members and function parameters have names. Simply represent these as C strings. Since, in some cases, these names are optional, allow NULL to be given for a name.
Technically parameters can have a "register" storage class. However, you can ignore this in your design.
You can ignore enumeration types and bitfield types in your design.
You can also ignore oldstyle function types that are created from function definitions. That is, you can assume an oldstyle function will have an empty parameter list.
Be sure to consider when failure is possible and in these cases either provide the caller with a status return value or consider it a fatal error. I don't care which approach you take, although consistency would be a good idea, but be sure you detect the errors.
Be sure to consider both "prototype" and "old-style" functions.
At the 80% level, you should implement your design. Put your implementation in a file named "types.c".
When printing types, you must employ some technique to avoid infinite recursion. Therefore consider carefully where recursion can occur in types. In these cases it is acceptable to limit the depth to which the print routine recurses.
At the 100% level, you should carefully test your implementation.
You should build a driver program that will thoroughly test your implementation. Put this driver program in a file called "main.c".
Your code will be graded using turing.unh.edu so be sure to test in that environment.
Your code should be submitted for grading from turing.unh.edu.
Be sure to properly structure and comment all your source code.
To turn in this assignment at the 60% level, type:
~cs712/bin/submit phase1 type.h
To turn in this assignment at the 80% level, type:
~cs712/bin/submit phase1 type.h type.c
To turn in this assignment at the 100% level, type:
~cs712/bin/submit phase1 type.h type.c main.c
Submissions can be checked by typing (also on turing.unh.edu):
~cs712/bin/scheck phase1
To receive credit for the assignment, you must turn in your files prior to 8am on Monday February 10. No late submssions will be accepted.
Remember: you are expected to do your own work on this assignment!
Comments and questions should be directed to hatcher@unh.edu