ECS 36A: Programming Assignment #4
Spring 2020
Contents
1 Changelog 1
2 Due Date 2
3 CSIF is the Reference Environment 2
4 General Submission Requirements 2
4.1 Submitting on Gradescope: Autograder Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
5 Manual Review 3
6 Parts 3
6.1 Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
6.2 Makefile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
6.3 sumArrs() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
6.4 strrpbrk() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
6.5 parseForHighest() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
6.6 minAtSameIndex() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
7 Grading Breakdown 6
1 Changelog
You should always refer to the latest version of this document.
• v.1: Initial version.
• v.2: Fixed typo regarding return value in directions for minAtSameIndex().
• v.3:
– In red, added clarification regarding input validation for sumArrs().
– In blue, made explicit what parseForHighest() is supposed to do (beyond the return value). Clarified input validation
as well.
• v.4:
– Clarified that each of test_arr_utils.c and test_str_utils.c should contain a main function.
– In the sumArrs_example.c, originally, str_utils.o seemed to be a dependency of sumArrs_example, based on the compilation
line that ran when make was used. This is incorrect, and I have fixed it, so now the example shows:
gcc -Wall -Werror -g sumArrs_example.c arr_utils.o -o sumArrs_example.
– I’ve added an additional example for strrpbrk().
• v.5:
– Stated that style guide can be found on Canvas.
– Made it more explicit that you cannot validate the length parameter in sumArrs().
∗This content is protected and may not be shared, uploaded, or distributed.
1
• v.6: Added sentence to end of second paragraph in section on parseForHighest(): “You don’t need to consider cases like
" ;; " or " ;" either.”
• v.7: (Released: 3:20 AM on May 9)
– Added clarification on input validation before the hint in the section on parseForHighest().
– Added to the strrpbrk() directions that you should not modify the original input string.
– Added autograder details.
2 Due Date
This assignment is due the night of Tuesday, May 12. Gradescope will say 1:00 AM on Wednesday, May 13, due to the “grace
period”. Do not rely on the grace period for extra time; this is risky.
3 CSIF is the Reference Environment
The reference environment is the CSIF. If you choose to not use the CSIF or a sufficiently similar Linux environment, you
run the risk of running into trouble. For Mac users, this risk involves that gcc on Macs seems to not report as many errors
(when the -Wall and -Werror flags are used) as gcc on a Linux machine. I’m not saying everyone has to use the CSIF; I’m
merely saying that the CSIF is guaranteed to be free of issues.
4 General Submission Requirements
You are only allowed to include the standard library header files listed below. If you find any that you would like to include,
feel free to ask me about it. My general rule is that I do not want you to include a header file that causes a key part of the
assignment to become trivial.
•
•
•
•
•
•
You are given the following files on Canvas. You cannot modify them.
• arr_utils.h
• str_utils.h
Your submission will consist of the following files:
• arr_utils.c
• str_utils.c
• Makefile
• test_arr_utils.c
• test_str_utils.c
The last three files will be graded during manual review, but the first two files will be graded by the autograder. (I might
have the autograder check that your last three files function properly as well, in which case I’ll let you know.)
4.1 Submitting on Gradescope: Autograder Details
Don’t forget that you can change which of any submission you’ve made to Gradescope is your active submission, as I
mentioned in this announcement here and demonstrated during the 04/29 lecture.
As stated above, the autograder will only grade arr_utils.c and str_utils.c, but the other three files (i.e. Makefile,
test_arr_utils.c, and test_str_utils.c) will be graded during manual review. Thus, at the very least, your final submission
should contain all five files. You could submit all five files on each submission if you wish. Note that if you change which
submission is your active submission before the deadline, you should make sure that that newly active submission contains
all five files, or else you may lose unnecessary points on manual review for not having the other three files.
2
You need to have definitions of all four functions (i.e. sumArrs() and minAtSameIndex() in arr_utils.c and strrpbrk() and
parseForHighest() in str_utils.c), even if you have not completed all four functions. Failure to do so can result in a linker
error even for the functions you have implemented. For example, if you have implemented sumArrs() but not minAtSameIndex(),
then you should put an empty “skeleton” for minAtSameIndex() in arr_utils.c, such as that shown below.
1 int minAtSameIndex (int * arr1 , int * arr2 , int * arr3 , int len , int * index )
2 {
3 return -1;
4 }
5 Manual Review
You can find the manual review guide on Canvas.
6 Parts
6.1 Tests
In test_arr_utils.c and test_str_utils.c, you will implement tests for the functions declared in arr_utils.h and str_utils.h,
respectively. (This part does not need to be done before all of the other parts.) Note that test_arr_utils.c and test_str_utils.c
must each contain a main function.
6.2 Makefile
Write a makefile called Makefile that compiles the executables test_arr_utils and test_str_utils. You need to properly identify
the dependencies here. For example, test_str_utils should depend on test_str_utils.c and str_utils.o. Your makefile should
have a clean rule. For this assignment, you do not have to use makefile variables or phony targets. However, you will be
penalized if your dependencies are wrong (e.g. if str_utils.o depends on test_arr_utils.c), and you will be penalized if you
do not use the -Wall and -Werror flags. (You can and should include the -g flag if you wish.) By the way, it’s not enough to
successfully compile your program with make to be assured that your dependencies are correct.
You can include a rule for an additional executable in your makefile, if you want to run a program that uses your functions
without running tests. For example, you can add a rule to compile a main executable from a main.c source file. You do not
have to do this.
If you wish to test your makefile, then I would recommend creating the source files test_arr_utils.c and test_str_utils.c,
each with empty main functions for now. Create arr_utils.c and str_utils.c as well and give them empty definitions (with
trivial return values).
As with regular source code and test cases, you should not be copying each other’s makefiles or copying your makefile
from other sources. Write your own makefile.
6.3 sumArrs()
In arr_utils.c, implement the function sumArrs that is declared in arr_utils.h. This function should compute the values of
outputArr (the fourth argument) such that the ith element of outputArr is the sum of the ith elements of arr1 and arr2 (the
first and second arguments, respectively). The function should return false if any null pointers are passed in. (In that case,
don’t worry about modifying outputArr.)
You may assume that the length parameter (i.e. the third parameter) is always the length of both of the first two arrays
and is always correct (unless one of the first two arrays is a null pointer). There is no way for your function to check if this
parameter is incorrect.
If outputArr is not a null pointer, you should assume that the array it references is at least as big as each of arr1 and arr2.
There really is no way that you can validate this assumption from within the function. (This is akin to how strcpy() cannot
verify that the destination buffer is large enough to contain the contents of the source string.)
Below are some examples of how your function should behave. In my own setup, I had a source file called sumArrs_example.c
and a rule in my makefile to create a corresponding executable sumArrs_example, but you do not need to do this. You can find
the example source files on Canvas here, but be careful about copy/pasting them from Canvas, as that may introduce odd
formatting issues.
1 $ cat sumArrs_example .c
2 # include " arr_utils . h"
3
4 # include < stdio .h >
3
5
6 int main ()
7 {
8 int arr1 [] = {5 , 8 , 3};
9 int arr2 [] = { -9 , 19 , 20};
10 int outputArr [3];
11 int retval = sumArrs ( arr1 , arr2 , 3, outputArr );
12 printf (" retval is %d\n" , retval );
13 for ( int i = 0; i < 3; ++ i)
14 printf (" outputArr [% d] is %d\ n", i , outputArr [i ]) ;
15 return 0;
16 }
17 $ make
18 gcc - Wall - Werror -g sumArrs_example . c arr_utils .o -o sumArrs_example
19 $ ./ sumArrs_example
20 retval is 1
21 outputArr [0] is -4
22 outputArr [1] is 27
23 outputArr [2] is 23
24 $
6.4 strrpbrk()
The name of this function will seem kind of stupid until we go over string functions this week. However, you should already
be able to implement this function.
In str_utils.c, implement the function strrpbrk that is declared in str_utils.h. This function should return a pointer to
the last occurrence in the first string of any of the characters that are in the second string. The function should return NULL
if there are no matches or if at least one null pointer is passed to the function.
Do not modify the original input string (i.e. the first argument).
Below are some examples of how your function should behave.
1 $ cat strrpbrk_example . c
2 # include " str_utils . h"
3
4 # include < stdio .h >
5
6 int main ()
7 {
8 char str [] = "Hi , how are you ?";
9 char * ptr = strrpbrk ( str , " yeo ") ;
10 printf (" ptr =% s\n" , ptr );
11
12 char str2 [] = " AA BBB C DDD EE ";
13 char * ptr2 = strrpbrk ( str2 , " ") ;
14 printf (" ptr2 =% s\n ", ptr2 );
15
16 return 0;
17 }
18 $ make
19 gcc - Wall - Werror -g strrpbrk_example .c str_utils . o -o strrpbrk_example
20 $ ./ strrpbrk_example
21 ptr = ou ?
22 ptr2 = EE
23 $
6.5 parseForHighest()
This function will be easier after we go over string functions this week.
In str_utils.c, implement the function parseForHighest that is declared in str_utils.h. This function expects a sequence of
integers given in a string in which a semicolon is between each pair of integers. For example, the sequence of integers 58, 2,
and -3 is represented as "58; 2; -3". The function should determine the highest integer in the sequence of integers and place
that value in the variable referenced by the second argument. The function should return false if at least one null pointer is
passed in and true otherwise. You may assume that the string containing the sequence of integers is properly formatted and
only contains digits, whitespace, and semi-colons (e.g. it won’t be something like "2 x ; 5;5&*8"); the only input validation
that you need to do for this function is checking if the caller passes in any null pointers as arguments. You don’t need to
consider cases like " ;; " or " ;" either.
4
If a null pointer is passed in, then it does not matter what value is placed in the variable referenced by the second
argument.
Hint: The Lecture #3 slides talk about type conversion functions. Your program should ignore whitespace (e.g. " 58; 2
; -3 "), but you might not need to do anything special to address this.
Below are some examples of how your function should behave.
1 $ cat parseForHighest_example .c
2 # include " str_utils . h"
3
4 # include < stdio .h >
5
6 int main ()
7 {
8 char str1 [] = "5;83;22;42";
9 int highest = -1;
10 int retval = parseForHighest ( str1 , & highest );
11 printf (" retval =% d \n", retval ) ;
12 printf (" highest =% d\n" , highest );
13 return 0;
14 }
15 $ make
16 gcc - Wall - Werror -g parseForHighest_example .c str_utils .o -o parseForHighest_example
17 $ ./ parseForHighest_example
18 retval =1
19 highest =83
20 $
6.6 minAtSameIndex()
In arr_utils.c, implement the function minAtSameIndex that is declared in arr_utils.h. This function takes three arrays of
integers, their length (you may assume they all have the same length and that the length is correct), and a variable for
storing the result. The function should return true if all three arrays have their minimums at the same index and false
otherwise. In the former case, the variable referenced by the fifth argument should be set to this index, and in the latter
case, it should be set to -1. If any null pointer is passed in, then the function should return false and do nothing else.
minAtSameIndex() becomes more fun/painful/complicated when we note that the minimum does not need to be unique. For
example, in the array containing the values 5, 8, 9, 5, and 20, the minimum (5) appears twice, at indices 0 and 3. Thus,
we will modify the goal of the function to say that the function should return true if all three arrays have a minimum at
a common index and false otherwise. If there are multiple indices that fulfill such critera, then the smallest one should be
returned placed into the variable referenced by the fifth argument.
Below are some examples of how your function should behave. Below those examples are explanations of the output.
1 $ cat minAtSameIndex_example .c
2 # include " arr_utils . h"
3
4 # include < stdio .h >
5
6 int main ()
7 {
8 printf ("=== Case #1 ===\ n ") ;
9 int arr1 [] = {5 , 19 , 20 , 4, 3, 5};
10 int arr2 [] = {700 , 200 , -1 , 53 , -89 , 70};
11 int arr3 [] = {53 , 44 , 22 , 19 , 18 , 19};
12 int index = -2;
13 int retval = minAtSameIndex ( arr1 , arr2 , arr3 , 6, & index ) ;
14 printf (" retval =% d \n", retval ) ;
15 printf (" index =% d\ n", index );
16
17 printf ("=== Case #2 ===\ n ") ;
18 int arr4 [] = {1 , 1 , 2, 3};
19 int arr5 [] = {4 , 3 , 3, 5};
20 int arr6 [] = { -1 , -1, 2, -1};
21 index = -2;
22 retval = minAtSameIndex ( arr4 , arr5 , arr6 , 4, & index );
23 printf (" retval =% d \n", retval ) ;
24 printf (" index =% d\ n", index );
25
26 printf ("=== Case #3 ===\ n ") ;
27 int arr7 [] = {5 , 0 , -1 , 13 , -1};
28 int arr8 [] = {40 , 20 , 300 , 20 , 19};
5
29 int arr9 [] = {0 , 1 , 2, 3, -5};
30 index = -2;
31 retval = minAtSameIndex ( arr7 , arr8 , arr9 , 5, & index );
32 printf (" retval =% d \n", retval ) ;
33 printf (" index =% d\ n", index );
34
35 printf ("=== Case #4 ===\ n ") ;
36 int arr10 [] = {5 , 5, 5 , 5 , 5 , 5 , 5, 5};
37 int arr11 [] = {10 , 1, 1, 1, 10 , 1, 1, 1};
38 int arr12 [] = {1 , 10 , 10 , 10 , 1, 10 , 10 , 10};
39 index = -2;
40 retval = minAtSameIndex ( arr10 , arr11 , arr12 , 8, & index ) ;
41 printf (" retval =% d \n", retval ) ;
42 printf (" index =% d\ n", index );
43
44 return 0;
45 }
46 $ make
47 gcc - Wall - Werror -g minAtSameIndex_example .c arr_utils .o -o minAtSameIndex_example
48 $ ./ minAtSameIndex_example
49 === Case #1 ===
50 retval =1
51 index =4
52 === Case #2 ===
53 retval =1
54 index =1
55 === Case #3 ===
56 retval =1
57 index =4
58 === Case #4 ===
59 retval =0
60 index = -1
61 $
Explanations:
• In Case #1, the minimums of the three arrays are 3, -89, and 18, respectively.
• In Case #2, the minimum of the first array occurs at indices 0 and 1, the minimum of the second array occurs at indices
1 and 2, and the minimum of the third array occurs at indices 0, 1, and 3. Thus, 1 is the smallest (and only) index at
which all three arrays see their minimums.
• In Case #3, the minimum of the first array occurs at indices 2 and 4, the minimum of the second array occurs at index
4, and the minimum of the third array occurs at index 4. Thus, 4 is the smallest (and only) index at which all three
arrays see their minimums.
• In Case #4, the minimum of the first array occurs at all indices, the minimum of the second array occurs at all except
indices 0 and 4, and the minimum of the third array occurs at indices 0 and 4. Thus, there is no index at which all
three arrays see their minimums, so the function returns false.
7 Grading Breakdown
Below is a likely breakdown of the grading of this assignment, which is worth 8% of your final grade:
• Correctness as determined by Gradescope autograder (visible/hidden test cases): 6%
– sumArrs(): 0.5%
– strrpbrk(): 1.5%
– parseForHighest(): 1.5%
– minAtSameIndex(): 2.5%
• Manual review: 2%
– Testing: 1%
– Makefile: 0.5%
– Consistency of style and quality of implementation: 0.5%