EECS 2031 Software Tools, Winter 2014
Lab 6 (lab open during first 30 minutes, then closed in labtest mode)
Cellphones and other electronic devices must be off while you are in the lab.
Background Scenario
This lab uses the same bathroom scale data transmission scenario as
lab2 to lab5.
Corrected:
However, this time you have to adapt your solution to handle arbitrarily long input.
In the following and for ease of reading, the changes relative to lab6
have been marked below with '***'.
As before, each line of input contains the following information:
timestamp userID weight
There are one more space characters separating the three pieces of information, except that
the userID itself may now contain one or more spaces (as in "1000 John Jack Smith 123.45").
The fields are defined as follows:
- The timestamp is an integer with the number of seconds since 00:00, Jan 1, 1970 UTC,
which conforms to the standard specification of time in Unix/Linux systems.
- The userID is a string, which may contain spaces.
- The weight as a floating point number, specified to mean the weight in kilograms.
This protocol can be parsed deterministically,
as the weight is the first numeric field after a sequence of text fields, e.g. as in
timestamp userIDa userIDb userIDc userIDd weight and none of the parts of
the userID can start with a digit or '.'.
Objective
- Write an ANSI-C program called lab6.c that reads lines from standard input,
parses them, and classifies the input according to the context set out above and the requirements
specified below.
- In the initial open lab, you are welcome to create a draft solution. You need to submit that using the command
submit 2031 pre6 lab6.c
With this, your initial work will be available to you in the closed part of the labtest.
You can submit other text files, such as files with input data, as well.
- Once the labtest starts, your work will be available to you in a subdirectory
called unsubmit in your home directory. This is a read-only location.
So you have to copy these files out first, e.g. via the following command
cp unsubmit/pre6/* ~
- Test that your program correctly implements the required functionality
- Finally, submit your solution electronically before the end of
the lab test using the command
submit 2031 lab6 lab6.c
- You may submit your solution more than once. Additional documentation about the submit
command can be viewed by typing man submit.
Now create a new ANSI-C program that does the following.
Requirements
Your program must the input read line by line from standard input.
- If the timestamp field is missing, is not an integer, or is zero,
you must print Invalid time, followed by a newline character.
- *** The userID consists of a sequence of text strings each of which cannot start with a
digit or '.' character.
In constrast to previous labs, your program needs to handle
arbitrarily long lines in the input as well as arbitrarily long userID's.
If the userID is missing or there is no valid userID, you must print
Illegal userID, followed by a newline character.
- *** You must create a new function to handle the line of input.
- If the weight field is missing, or is less than 30.0 or more than 300.0,
you must print Illegal weight, followed by a newline character.
- If the timestamp of a record not larger than the previous timestamp,
i.e., the current is in the past relative to the previous one or identical to it,
you must print Nonmonotonic timestamps, followed by a newline character.
- Additional text on the line after the last field should be silently ignored.
- If there are multiple problems with the line of input, you must print only
the message for the first field that does not follow the specification. Processing should
then continue with the next line. All rules need to be applied in the order specified here.
- Data from lines that pass all above criteria are considered valid records.
-
If the information supplied in each line is otherwise fine,
and the userID is new, i.e., has not been seen before, you must print OK newuser
followed by a newline character.
Different amounts of whitespace
between the parts of a userID should be ignored in the test for equality of userID's.
- Otherwise, the userID has been seen before.
If the weight change between the current record and the last valid record
for the same userID exceeds 10 kg/day,
you must print Suspiciously large weight change, followed by a newline character.
Otherwise, you must print OK, followed by a newline character.
-
When the processing reaches the end of the input, i.e., upon EOF, the program
must output a bar chart, using ASCII characters.
This bar chart must contain vertical and horizontal axes drawn with '|' and '-' characters,
respectively. The origin must be represented as a '+' character.
The "length" of the horizontal dimension needs to match the amount of data that can be shown,
as specified below.
The bar chart must always be 10 lines "high" (plus the line for the horizontal axis).
-
The bar chart must show the change of weight over time for the userID with the last valid record.
For this, you must scale the information so that
30kg and 300kg are represented by 1 and 10 '*' characters respectively as vertical bars.
You must truncate weight values, i.e., a weight of 59.999kg will still yield only a single star.
To simplify the lab, the time dimension on the horizontal axis must correspond only
to the sequence of weight records, and must not be spaced according to the time stamps themselves.
Thus, each record should be respresented by a single character in the horizontal dimension.
-
You are required to use a dynamically allocated 2D array for your solution.
- No other output must be produced.
For the purpose of this lab, you do not need to worry about numeric overflow. In other words, you
can safely assume that timestamps are guaranteed to fit in 32 bit integers, and floating point numbers will fit into a ANSI-C float variable.
You can also safely assume that there is always at least one (or more) space characters
between the fields and between each part of the userID.
***
However, in this lab there is no limit on the line length for the input, nor for the length
of the userID.
Here is an input file with long lines, input.txt.
If you start your program with this, you should get the following output
attached again as a file expectedoutput.txt.
Hints:
- I suggest you write a function that handles the reading of the input.
It will include a loop that repeatedly reallocates memory to handle the potentially
long line of input. Then return the pointer to the allocated memory to the main program.
Don't forget to free that memory after you have used all the information from the line.
- Remember to handle the case of very long userID's not only in the input but also
in other places, such as the linked list.
- It is usually easier to address each individual requirement to your code only after
you have verified that the previous requirement is met by your program.
- Remember to look up information related to this lab well in advance or (at the very latest)
in the first 30 minutes of the lab.
- Many of the test cases for previous labs are still valid for lab6.
You can use those test cases to test if your submission deals correctly with the
unchanged aspects of the specification.
Additional hints:
- fgets() will read the newline character at the end of the line and terminate the string with a '\0', which enables you to use all string functions. Searching for that newline character, e.g., with strchr(), is an easy way to detect if one is finished with reading the line or not.
- After you have read the long line, the maximum length that the userID can have is the length of said line. This enables you to allocate an array long enough to assemble the parts of the userID as before.