Homework 8 Intro to C – 21tenmo Solution

Now that you are experienced with assembly, it’s time to dive into the magical world of C programming! In this assignment, you will be creating a simple command-line program called 21tenmo (yes our 2110 version of Venmo!!!) for managing a database of "Accounts" represented in a comma separated values (.csv) format. On a high-level, you will be implementing functionality for adding a new account to the database from the command line along with several other functionalities for allowing an account holder to perform various operations. There are a lot of details, edge cases, and error checking to cover so we highly recommend going through the entire pdf and the source code comments before you start.


    • Learning Outcomes

        1. Understanding C Syntax & Keywords

        2. C Program Control Flow

        3. Basic Command Line I/O

        4. Compiling, Running, and Debugging C Programs


    • Description

3.1    Provided Files (excluding any tester    les)

    1. 21tenmo.c (TO BE IMPLEMENTED)

    2. main.c (TO BE IMPLEMENTED)

    3. 21tenmo.h (TO BE MODIFIED)

    4. errcodes.h (DO NOT MODIFY)

    5. Make le (DO NOT MODIFY)

    6. info.csv (The Database to be used/modi ed)

    7. utility.o (See subsection on utility functions)

3.2    Utilty Functions

The following functions are part of the utility object le which you should use in your program wherever necessary. The prototypes of these functions can be found in 21tenmo.h, however, keep in mind that in order to make everything more simpli ed, the implementation of these functions are not available for your view.

    1. void readCSV(void)

This function validates and reads the sorted info.csv database into the global array (arr) while in-crementing the variable DBsize to re ect the number of entries in the database. The reading should happen before any modi cation is performed in the program. If an invalid row is found in the database, a useful error message is printed out for you and the program is halted.

    2. void writeCSV(void)

This function writes the contents of the global array (arr) into the info.csv (database) by replacing the entire le. writeCSV only writes rows with an active accountNumber (i.e. accountNumber != 0) to the csv database. Keep in mind that all oating points are truncated to double-precision format.


2

    3. void getLine(char *buffer, int size)

This is a helper function for reading user input from the standard input (stdin, console). You are REQUIRED to use this method instead of any other available standard C functions (e.g. scanf, getline, etc.). This function takes in a length-speci ed bu er (e.g. char bu er[5]) and reads a NULL terminated string into the passed in bu er. This function also takes in a size variable which represents the number of characters to read from standard input (stdin). This helper function is super useful as it will discard any inputs passed the bu er size for avoiding bu er over ow issues as much as possible.

    4. void myExit(int status)

This is a wrapper function for the standard library exit() function. You are required to use this function whenever the program halts normally (i.e. status = EXIT SUCCESS) or whenever you need to terminate the program from continuing due to bad input, etc. See here for more details on these macros.

    5. void printArray(int numElements)

This is a helper function provided solely for debugging purposes. This function will print out the values of the numElements of items from the global array at run-time. numElements is the number of elements to print to standard output (stdout) [1, MAX CSV SIZE].


3.3    Implementation

BEFORE START IMPLEMENTING ANY FUNCTIONS, MAKE SURE YOU READ THE ’IMPORTANT NOTES’ SECTION.

First look at the header le, 21tenmo.h which needs to be modi ed rst. This le contains the de ni-tions for structs and macros used in this program. In this particular header, you will need to implement the Account struct (you can read about typedefs here) with the following EXACT eld names and EXACT data types.


accountNumber, an unsigned integer (already provided)

personName, a character array of size MAX NAME SIZE + 1 (space for the NULL terminator) balance, a oat

requesterNumber, an unsigned integer requestAmount, a oat


In the main.c le, you will need to implement the main method that checks for command line arguments preceded by ags ’-a’ or ’-l’ (see printUsage() and section 5.1 for more details). If the arguments passed in are not preceded by ’-a’ (for adding an account to DB) or ’-l’ (for logging in a current user), you should print the correct usage and call myExit using EXIT FAILURE. If the correct ags are provided:


-a should be followed by a string of the person’s name (surrounded by quotations ""), i.e. "Kendrick Lamar". This person should then be added to the database with the next available accountNum-ber (with other elds being set to default value of zero).


-l should be followed by an integer value representing a person’s account number.  If the account number speci ed is invalid, an error message should be shown and you should call myExit using

EXIT FAILURE.






3

If any of the above speci cation are not met following the correct ags, you should call myExit using EXIT FAILURE. Else, display the user’s options by calling the provided function, userMenu, after validat-ing the accountNumber. Continue running the program until they save and exit.


Notice that there’s already a global variable ’myErrNo’ for setting error codes upon successful or failed termination of the program depending on what went wrong. Now open up errcodes.h and read the comments associated with each error code. Throughout the program, you are responsible for setting the correct error codes (or NO ERROR) before termination of the program, especially if a database operation fails. This is a common way of being informed of the results of a program execution in C (for more info, look into C’s errno and errno.h, however, keep in mind that we have our own pre-de ned error codes in errcodes.h).


Functions to implement or modify:

Note: For any function that deals with input parsing/validation check the section on ’Helpful Man Pages/String functions’.

executeCommand(): You must implement code to show the user’s balance, and update the csv (see the subsection on utility functions) in the case where the user wants to exit.

modifyBalance(): This function should take user input (both negative and positive) to modify the balance of the user’s account. Make sure that if the user is withdrawing money, they have enough in their account to withdraw the amount requested (a user’s balance should never be negative). You should also print the amount modi ed by at the end of the transaction.

sendMoney(): This function should allow a user to send funds to another user by specifying their account number and an amount (see formatAndCheckCurrency()). This transaction should fail if: the account number speci ed is invalid or inactive, the account number speci ed is the same as the users’, the amount speci ed is negative, or nally if you don’t have enough funds to send the requested amount. Update the required elds of the corresponding accounts on success.

formatAndCheckCurrency(): This is the function that should validate any input amount in other functions. This function check’s that an amount speci ed is valid, meaning it contains the following characters: commas, at most one period (for decimals), at most one minus sign (for negative values), and other than that it should be all numbers. The function should return 0 on success and nonzero value otherwise. Note that you do not need to perform comma validation, upon error, the passed in currencyString should not be modi ed. Some valid cases are: 1000, 10000.00, 1,0,0,0,0.00. Some invalid cases are - -1000.00, 1/00.00.

requestMoney(): This function should allow a user to request money from another user by specify-ing their account number, and an amount. This function should fail if: The account number speci ed is invalid or inactive, if the account number speci ed is the same as the users’, the account speci ed already has a request pending, or nally if the amount requested is negative (make sure the correspond-ing errorcode is set in case of failure). Don’t forget to Update the request elds for the corresponding account upon success.

checkRequests(): This function should allow a user to check their requests and approve or deny the request received by entering ’Y’ or ’N’. The request should be displayed with the account number it was sent from, and the amount requested. If the request is denied OR the request is approved and amount requested is higher than the users’ balance then the request should be cancelled. If input is other than ’Y’ or ’N’ an error message should be displayed and the request should not be modi ed. If there are no pending requests for the logged in account, this function should print a message and return.









4
3.4    Example Execution


































































5












































    • Important Notes

        1. accountNumber(s) should start at FIRST ACCOUNT NUMBER and increase in order every time an account is added to the database all the way to the maximum size of the DB (Hint: create a macro for the upper boundary for account validation checks). Keep in mind that at any time the database size should not exceed the MAX CSV SIZE macro.

        2. A valid accountNumber (accountNumber in range) that is not in the DB (e.g. accountNumber = 2120 but there isn’t an account associated with that number) is considered an INACTIVE account (meaning that once read into the global array, accountNumber of that index is zero).

        3. The personName’s length should be within the MIN NAME SIZE and MAX NAME SIZE (see 21tenmo.h for more information regarding the NULL terminator.

        4. The database should only be modi ed (written back) when a user is done with all operations and exits the program, see example for operation ’6’ (Save and Exit).




6

    5. As mentioned in section 3.3, make sure that myErrNo is set to the correct errcode (e.g. myErrNo = ERR INVALID AMOUNT whenever the parsed/passed in amount is invalid).

    6. For all  oating point operations make everything double-precision format (i.e. $25.12).

    7. DO NOT call getLine or any other input-reader method more than necessary. For example, if you are getting an accountNumber and amount, you should only call getLine twice.

    8. DO NOT modify the given include(s) list. All necessary libraries are already included.

    9. DO NOT try to read and write the database with functions/code other than the provided readCSV() and writeCSV() utility functions. Use the myExit function provided instead of stdlib’s exit function.

    10. DO NOT modify the given macros and function prototypes and declarations (we are going to test the given functions but you are allowed to create your own helper functions if you want).

    11. There are many checks and validations in place for database (info.csv) entries that will block your program from running if an invalid row is found, therefore, be very careful with manually modifying the .csv le.

    12. Wherever applicable, DO NOT use hard-coded sizes, try using the built-in sizeof operator instead (this is a very important concept in any C program).

    13. Although you are not gonna be tested on bu er over ows, whenever a bu er is necessary (e.g. before calling getLine), make sure you do not allocate more than what’s needed (or less than :D); this goes for input reading and parsing as well. However, DO NOT dynamically allocate any memory (malloc, calloc, realloc, etc.).

    14. We highly recommend that you create your own macros for usage in your program. Feel free to add them in 21tenmo.h (or the C le if it is only used in one le) as you see t.



    • Useful Tips

5.1    Command Line Arguments

When you write a C program, you can work with arguments you receive on the command line through two parameters you receive in the main function, argc and argv.

argc: The number of command line arguments you receive.

argv: An array of your command line arguments in string form.

Note: the zeroth argument to your program is always going to be the name of the program itself. This means that argc and argv will indicate that you have one more parameter than you might expect.

5.2    Helpful Man Pages/String functions

The following are some helpful functions you should know to complete this homework. To get more detailed descriptions of any of these functions, or others in the C standard library, type into your terminal emulator:

$ man <function_name>

This will print the corresponding man page for that function.

int strcmp(const char *s1, const char *s2)

This function allows you to compare two strings. Returns 0 if they are the same, and a nonzero value otherwise.


7
size t strlen(const char *str)

This function returns the length of the string passed in. (note: size t is an unsigned integer data type).

char *strcpy(char *dest, const char *src)

This function copies the ’string’ pointed to by src to the dest(ination) bu er.

unsigned long int strtoul(const char *nptr, char **endptr, int base)

This function allows you to pass in a string and base (you’ll usually want base 10) and will return the integer value of the string you passed in, according to the speci ed base. It will return 0 in case of invalid parameters. For now, you may replace the ’endptr’ argument with NULL (we recommend understanding the type of this argument and how it is used). Use this function instead of other functions such as atoi.

float strtof(const char *nptr, char **endptr)

This function is similar to strtoul but will convert the string to  oat instead.


5.3    Debugging with GDB

If you run into a problem when working on your homework, you can use the debugging tool, GDB, to debug your code! Former TA Adam Suskin made a series of tutorial videos which you can nd here here.

When running GDB, if you get to a point where user input is needed, you can supply it just like you normally would. When an error happens, you can get a java-esque stack trace using the backtrace(bt) command.


    • Checking Your Solution





































8

We have provided a Make le for this assignment that will build your project. (We highly recommend looking at the Make le source and familiarizing yourself with Make and GCC for future)

Here are the available commands for your usage with this Make le:

To compile and run the program with di erent command-line arguments rst run: make 21tenmo then upon a successful compilation, run the program as speci ed by its usage (e.g. ./21tenmo [flag] [argument]).

OR:

    1. To clean your working directory (use this instead of manually deleting the .o  les): make clean

    2. To run the tests without gdb: make run-tests

    3. To run a speci c test case: make check-tests TEST=test case name

    4. To run the tests with gdb (except main.c due to the way autograder is setup): make run-gdb


Your les must compile with our Make le, which means it must compile with the following gcc ags (taken from the Syllabus):

-std=c99 -Wall -pedantic -Wextra -Werror -O2 -Wstrict-prototypes -Wold-style-definition -g

All non-compiling homeworks will receive a zero. If you want to avoid this, do not run gcc manually, use the Make le as described above.

Note: The grade (or percentage) that you see locally (from the check library) might be slightly di erent from the grade on Gradescope (which is the overall grade).


Note: Due to the nature of this program (I/O), the checker may not re ect your actual grade on this assignment. We reserve the right to update the checker as we see t when grading your solution.


    • Deliverables

Submit ONLY the following    les (all at the same time) to Gradescope under the Homework 8 assignment:

    1. 21tenmo.c

    2. 21tenmo.h

    3. main.c

Please check your submission after you have uploaded it to Gradescope to ensure you have submitted the correct les.

Homework due date: October 24, 2019.


    • Rules and Regulations

8.1    General Rules

    1. Starting with the assembly homeworks, any code you write must be meaningfully commented. You should comment your code in terms of the algorithm you are implementing; we all know what each


9

line of code does.

    2. Although you may ask TAs for clari cation, you are ultimately responsible for what you submit. This means that (in the case of demos) you should come prepared to explain to the TA how any piece of code you submitted works, even if you copied it from the book or read about it on the internet.

    3. Please read the assignment in its entirety before asking questions.

    4. Please start assignments early, and ask for help early. Do not email us the night the assignment is due with questions.

    5. If you nd any problems with the assignment it would be greatly appreciated if you reported them to the author (which can be found at the top of the assignment). Announcements will be posted if the assignment changes.

8.2    Submission Conventions

    1. All les you submit for assignments in this course should have your name at the top of the le as a comment for any source code le, and somewhere in the le, near the top, for other les unless otherwise noted.

    2. When preparing your submission you may either submit the les individually to Canvas/Gradescope or you may submit an archive (zip or tar.gz only please) of the les. You can create an archive by right clicking on les and selecting the appropriate compress option on your system. Both ways (uploading raw les or an archive) are exactly equivalent, so choose whichever is most convenient for you.

    3. Do not submit compiled les, that is .class les for Java code and .o les for C code. Only submit the les we ask for in the assignment.

    4. Do not submit links to les. The autograder does not understand it, and we will not manually grade assignments submitted this way as it is easy to change the les after the submission period ends.

8.3    Submission Guidelines

    1. You are responsible for turning in assignments on time. This includes allowing for unforeseen circum-stances. If you have an emergency let us know IN ADVANCE of the due time supplying documenta-tion (i.e. note from the dean, doctor’s note, etc). Extensions will only be granted to those who contact us in advance of the deadline and no extensions will be made after the due date.

    2. You are also responsible for ensuring that what you turned in is what you meant to turn in. After submitting you should be sure to download your submission into a brand new folder and test if it works. No excuses if you submit the wrong les, what you turn in is what we grade. In addition, your assignment must be turned in via Canvas/Gradescope. Under no circumstances whatsoever we will accept any email submission of an assignment. Note: if you were granted an extension you will still turn in the assignment over Canvas/Gradescope.

    3. There is a 6-hour grace period added to all assignments. You may submit your assignment without penalty up until 11:55PM, or with 25% penalty up until 5:55AM. So what you should take from this is not to start assignments on the last day and plan to submit right at 11:54AM. You alone are responsible for submitting your homework before the grace period begins or ends; neither Canvas/Gradescope, nor your aky internet are to blame if you are unable to submit because you banked on your computer working up until 11:54PM. The penalty for submitting during the grace period (25%) or after (no credit) is non-negotiable.





10
8.4    Syllabus Excerpt on Academic Misconduct

Academic misconduct is taken very seriously in this class. Quizzes, timed labs and the nal examination are individual work.

Homework assignments are collaborative, In addition many if not all homework assignments will be evaluated via demo or code review. During this evaluation, you will be expected to be able to explain every aspect of your submission. Homework assignments will also be examined using computer programs to nd evidence of unauthorized collaboration.

What is unauthorized collaboration? Each individual programming assignment should be coded by you. You may work with others, but each student should be turning in their own version of the assignment. Submissions that are essentially identical will receive a zero and will be sent to the Dean of Students’ O ce of Academic Integrity. Submissions that are copies that have been super cially modi ed to conceal that they are copies are also considered unauthorized collaboration.

You are expressly forbidden to supply a copy of your homework to another student via elec-tronic means. This includes simply e-mailing it to them so they can look at it. If you supply an electronic copy of your homework to another student and they are charged with copying, you will also be charged. This includes storing your code on any site which would allow other parties to obtain your code such as but not limited to public repositories (Github), pastebin, etc. If you would like to use version control, use a private repository on github.gatech.edu

8.5    Is collaboration allowed?

Collaboration is allowed on a high level, meaning that you may discuss design points and concepts relevant to the homework with your peers, share algorithms and pseudo-code, as well as help each other debug code. What you shouldn’t be doing, however, is pair programming where you collaborate with each other on a single instance of the code. Furthermore, sending an electronic copy of your homework to another student for them to look at and gure out what is wrong with their code is not an acceptable way to help them, because it is frequently the case that the recipient will simply modify the code and submit it as their own.


























Figure 1: Collaboration rules, explained colorfully




11