COP3502-Assignment 1 Varg Solved

In this assignment, you’ll write two variadic functions – functions that take variable numbers of arguments, just like printf() is capable of doing. (There are also two other functions for you to write. A complete list of required functions, including their functional prototypes, is given below in Section 8, “Function Requirements”.)

You will submit a single source file, named Varg.c, that contains all required function definitions, as well as any auxiliary functions you deem necessary. In Varg.c, you will have to #include any header files necessary for your functions to work, including the custom Varg.h file we have distributed with this assignment (see Section 5, “Varg.h”).

Note: You will not write a main() function in the source file you submit! Rather, we will compile your source file with our own main() function(s) in order to test your code. We have attached example source files that have main() functions, which you can use to test your code. You can write your own main() functions for testing purposes, but the code you submit must not have a main() function. We realize this is completely new territory for most of you, so don’t panic. We’ve included instructions for compiling multiple source files into a single executable (e.g., mixing your Varg.c with our Varg.h and testcaseXX.c files) in Sections 11 and 12 of this PDF.

Although we have included test cases with sample main() functions to get you started with testing the functionality of your code, we encourage you to develop your own test cases, as well. Ours are by no means comprehensive. We will use much more elaborate test cases when grading your submission.

Start early. Work hard. Good luck!

2. Important Note: Test Case Files Look Wonky in Notepad
Included with this assignment are several test cases, along with output files showing exactly what your output should look like when you run those test cases. You will have to refer to those as the gold standard for how your output should be formatted. Please note that if you open those files in Notepad, they will appear to be one long line of text. That’s because Notepad handles end-of-line characters differently from Linux and Unix-based systems. One solution is to view those files in an IDE (like CodeBlocks), or you could use a different text editor (like Atom or Sublime).

3. Adopting a Growth Mindset
A word of advice before we dive in to the details: When faced with an assignment like this, which has many different facets, some of which might appear foreign and/or challenging, it’s important not to look at it as an instrument that is being used to measure how much you already know (whether that’s knowledge of programming, operating systems, or even what some might call “natural intellectual capability”). Rather, it’s important to view this assignment as a chance to learn something new, grow your skill set, and embrace a new challenge.

It’s also important to view intellectual capability as something that can grow and change over one’s lifetime. Adopting that mindset will allow you to reap greater benefits from this assignment (and from all your college-level coursework) regardless of the grades you earn.

For more on the importance of adopting a growth mindset throughout your academic career and how that can impact your life, see the following:

Growth Mindset vs Fixed Mindset: An Introduction (Watch time: 2 min 42 sec)

The Power of Belief – Mindset and Success (Watch time: 10 min 20 sec)

4. Writing Variadic Functions
One of the trickiest things about writing a variadic function is that you must somehow tell the function how many arguments you’re passing to it. When you call printf(), you do this implicitly, because printf() goes through your first argument (a string), and every time it sees a conversion code (such as “%d” or “%c”), it knows there is another input argument waiting to be processed. By reading the format string, the function figures out how many arguments to read after the initial one.

Included with this assignment is a file called varsum.c, which I wrote to show you how to implement a simple function to add up an arbitrary number of integer arguments passed to a function. The file has two versions of that function: mySum() and myOtherSum(). The only difference between the two implementations is how each function figures out how many integers it will be processing.

From that source file, you’ll see that when writing a variadic function, all the magic happens with the va_list data type and the va_start and va_arg functions. In order to use va_list, va_start, and va_arg, you must include stdarg.h at the top of your source code, like so:

#include <stdarg.h

Note that stdarg.h is a standard system library, just like stdio.h and string.h.

5. Varg.h
Included with this assignment is a customer header file that includes functional prototypes for all the functions you will be implementing. You should #include this file from your Varg.c file, like so:

 

#include "Varg.h"

The “quotes” (as opposed to <brackets) indicate to the compiler that this header file is found in the same directory as your source, not a system directory.

You should not modify Varg.h in any way, and you should not send Varg.h when you submit your assignment. We will use our own unmodified copy of Varg.h when compiling your program.

If you write auxiliary functions (“helper functions”) in your Varg.c file (which is strongly encouraged!), you should not add those functional prototypes to Varg.h. Our test case programs will not call your helper functions directly, so they do not need any awareness of the fact that your helper functions even exist. (We only list functional prototypes in a header file if we want multiple source files to be able to call those functions.) So, just put the functional prototypes for any helper functions you write at the top of your Varg.c file.

Think of Varg.h as a bridge between source files. It contains functional prototypes for functions that might be defined in one source file (such as your Varg.c file) and called from a different source file (such as the testcaseXX.c files we have provided with this assignment).

6. Test Cases and the test-all.sh Script
We’ve included multiple test cases with this assignment, which show some ways in which we might test your code. These test cases are not comprehensive. You should also create your own test cases if you want to test your code comprehensively. In creating your own test cases, you should always ask yourself, “How could these functions be called in ways that don’t violate the program specification, but which haven’t already been covered in the test cases included with the assignment?”

We’ve also included a script, test-all.sh, that will compile and run all test cases for you. You can run it on Eustis by placing it in a directory with Varg.c, Varg.h, and all the test case files, and typing:

bash test-all.sh
7. Output
The functions you write for this assignment should not produce any output. If your functions cause anything to print to the screen, it will interfere with our test case evaluation.