代写一个iCalendar格式的文件解析器，熟悉RFC 5545协议。
Description
In this assignment, you need to implement a library to parse the iCalendar files. The link to the format description is posted in the Assignment 1 description. Make sure you understand the format before doing the assignment.
According to the specification (RFC 5545), an iCalendar object contains:
- two specific required properties that must appear exactly once
- several optional properties
- one or more component
Our Assignment 1 parser will assume a somewhat simpler iCalendar file:
- two specific required properties (see the format description)
- Exactly one component - an event
This structure is represented by the Calendar type in CalendarParser.h
According to the specification (RFC 5545), an event component contains:
- two specific required properties that must appear exactly once
- an arbitrary number of optional properties
- 0 or more alarm components
Similarly, an alarm component also contains two required properties and an arbitrary number of optional ones.
These structures are represented by the Event and Alarm types in CalendarParser.h
The header also contains a type for representing the date-time property, a few headers, and a couple of other helpful definitions.
Your assignment will be graded using an automated test suite, so you must follow all requirements exactly, or you will lose marks.
Required Functions
1 | ErrorCode createCalendar(char* fileName, Calendar** obj) |
This function does the parsing and allocated a Calendar object. It accepts a filename and an address of a Calendar pointer (i.e. a double pointer). If the file has been parsed successfully, the calendar object is allocated and the information is stored in it. The function then returns OK. However, the parsing can fail for various reasons. In that case, the obj argument is set to NULL and createCalendar returns a variety of error codes to indicate this:
- INV_FILE is returned if there’s a problem with file argument - its null, it;’s a empty string, file doesn’t exist or cannot be opened, file doesn’t have the .ics extension, etc.
- INV_VER is returned if the calendar version property is present but malformed
- DUP_VER is returned if the calendar version property appears more than once
- INV_PRODID is returned if the product ID property is present but malformed
- DUP_PRODID is returned if the product ID property appears more than once
- INV_CAL is returned is the calendar itself is invalid (missing required properties or components, invalid opening/ closing tags, etc.)
- INV_CREATEDT is returned if the event creation date-time property is malformed in some way
- INV_EVENT is returned if the event component is malformed in some way
1 | char* printCalendar(const Calendar* obj); |
This function returns a humanly readable string representation of the entire calendar object. Sample output will be added to the assignment description. It must not modify the calendar object in any way. The function must allocate the string dynamically.
1 | void deleteCalendar(Calendar* obj) |
This function deallocates the frees object, including all of its subcomponents.1
const char* printError(ErrorCode err)
This function returns a string based on the ErrorCode value to make the output of your program easier to understand - i.e. “OK” if err is OK, “INV_FILE” or “invalid file” is INV_FILE was passed, etc.. The function must allocate the string dynamically.
Additional guidelines and requirements
While the above functions are required, you will need to write a number of helper functions. At the minimum, you will need print/compare/delete functions for properties and alarms, so you can store them in a list. In addition, it is strongly recommended that you write additional helpers functions for parsing the file - e.g. parsing an event, an alarm, or a date-time. You should also write delete functions for all the structs, since they will all be dynamically allocated.
All functions (required and not) must be in a file called CalendarParser.c. For your own test purposes, you will also want to code a main program in another .c file that calls your functions with a variety of test cases, but you won’t submit that program. Do not put your main() function in CalendarParser.c, or else the test program will fail due to multiple definitions of main(); you will lose marks for that.
Applications will #include CalendarParser.h in their main program. A basic CalendarParser.h has been provided for you. You must customize the file header with your student name and number. However, do not change the given typedefs or function prototypes, or else your utilities will not compile with the test program. Also, do not add any other functions, types, or headers. CalendarParser.h is the public “face” of our calendar API. All the helper functions are internal implementation details, and should not be visible to the
You are free to create your additional “helper functions” in CalendarParser.c, each with its proper function header, if you find some recurring processing steps that you would like to factor out into a single place. They must be in a separate header file, since they are internal to your implementation and not for public users of the utility package.
Your functions are supposed to be robust. They will be tested with various kinds of invalid data and must detect problems without crashing. However, be sure to follow the specification regarding return values. If your helper functions encounter a problem, they must free all memory and return the appropriate ErrorCode value.
Libraries are written with very specific requirements. They must have a clear public API, and they must communicate errors to the higher-level modules, which will then handle these errors. They should definitely not print their own error messages!
Important points
- Do be careful about upper/lower case.
- Do not put any internal helper function headers into CalendarParser.h
- Do not not change the given typedefs or function prototypes CalendarParser.h
- Do not submit any main() functions
- Do not exit the program from one of the parser functions if a problem is encountered, return an error value.
- Do not print anything to the command line.
The submission must have the following directory structure:
assign1/ - contains the README file and the Makefile
assign1/bin - should be empty, but this is where the Makefile will place the shared lib files
assign1/src - contains CalendarParser.c and LinkedListAPI.c
assign1/include - contains CalendarParser.h, LinkedListAPI.h, and your additional headers
Makefile
You will need to provide a Makefile with the following functionality:
- make list creates a static library libllist.a in assign1/bin
- make parser creates a static library libcparse.a in assign1/bin
- make or make all creates libllist.a and libcparse.a in assign1/bin
- make clean removes all .o and .so files
Evaluation
Your code must compile, run, and have all of the specified functionality implemented. Any compiler errors will result in the automatic grade of zero (0) for the assignment.
Marks will be deducted for:
- Incorrect and missing functionality
- Deviations from the requirements
- Run-time errors
- Compiler warnings
- Memory leaks
- Bad /inconsistent indentation
- Bad variable names
- Insufficient comments
- Failure to follow submission instructions
Submission
Submit your files as a Zip archive using Moodle. File name must be be A1FirstnameLastname.zip.