CSE 333 Exercise 1

Out: Wednesday, January 7
Due: Friday, January 9 by 11 AM
Rating: 2 ()

CSE 333 Exercise Rating Scale

Each exercise this quarter is rated on a integer scale of 1 – 5, inclusive, with 1 being the "least time-consuming" and 5 being the "most time-consuming".

This difficulty scale is meant as a rough guide for you in predicting the amount of time to set aside for each exercise as you balance the work required for 333 with your other obligations. However, it is necessarily imperfect as everyone's set of circumstances and experiences with the exercises differ. If your experience with an exercise does not align with its rating, that is not a reflection of you or your abilities.

Goals

Implement and use a function with array parameters.
Examine the relationship between pointers and arrays.
Use format specifiers to handle printing fixed-width integers.

Background

As discussed in lecture, arrays and pointers are closely related:

When used in an expression, an array name evaluates to a pointer.
Array subscripting notation is actually pointer manipulation: ar[i] ↔ *(ar+i).
An array argument and a pointer argument are functionally equivalent in that the function receives a copy of the pointer.

Problem Description

Write a C program (ex1.c) that does the following:

Contains a function called CopyAndSort that accepts, in order, two arrays of int16_t's and an array length as arguments; you should assume the length of the two arrays are the same. The function should iterate through the elements of the first array and use insertion sort to store them into the second array in non-decreasing (i.e., ascending with duplicates allowed) sorted order.
Write a main function that exercises your CopyAndSort function. When your program runs, it should sort the following array and print out the results:
```
{14, -5, 8, -17, 333, 42, -10, 8, -10}
```

When your program compiles and runs, we should see:

$ gcc -Wall -g -std=c17 -o ex1 ex1.c
$ ./ex1
-17 -10 -10 -5 8 8 14 42 333
$

Implementation Notes

Your code should insert the array elements in the proper place one at a time as they are copied. Do not copy the entire array first and then sort it.
The array lengths and subscripts can be stored in variables of type int.
- Note: in systems code we often prefer to use types like int32_t with precisely known sizes, but we also want to follow the Google style guide, which says that if all you need is an int, you should use int. For this exercise, we'll use arrays whose elements have explicitly-sized integer elements, but the array sizes and indices are ordinary integer values.
Depending on your implementation, you may get a compiler warning stating: 'sizeof' on array function parameter.... We encourage you to stop and think why gcc believes it is worth warning you about this. It is fine for your submission to generate this warning when compiled; however, you should fix any other compiler warnings you get in your code.

Style Focus

Don't forget that all of the good practices from previous exercises still apply!

General

For the sake of our autograder, make sure that your function names match the specifications exactly, including capitalization.

Program Layout

You should decompose the problem into multiple functions, if appropriate. As with the previous exercise, make sure that you organize and comment your functions in such a way that follows the best C practices.

Format Specifiers

Utilize the correct format specifiers to avoid implicit casts and to increase the portability of your code (i.e., use the format specifier for int16_t values). Explore the stdint.h and inttypes.h libraries.

Constants

Avoid "magic numbers" (i.e., unnamed numerical constants) where possible. Use predefined constants (e.g., EXIT_SUCCESS), if available, or use #define to define/name any integer constants that have a clear and specific use.

Submission

Submit the following file(s) directly to Gradescope:

ex1.c

Starting with Exercise 2, you will asked to submit exercises using GitLab tags. We recommend starting to use the provided Gitlab exercise repo and the tagging instructions found on the 333 Gitlab Guide.

Your code must:

Compile without errors or warnings on CSE Linux machines (lab workstations, attu, or CSE home VM).
Have no runtime errors, memory leaks, or memory errors (gcc and valgrind).
Be contained in the file listed above that compiles with the command:
```
$ gcc -Wall -g -std=c17 -o ex1 ex1.c
```
Have a comment at the top of your .c file with your name(s) and CSE or UW email address(es).
Be pretty: the formatting, modularization, variable and function names, commenting, and so on should be consistent with class style guidelines. Additionally, the linter shouldn't have any complaints about your code (cpplint.py --clint).
Be robust: your code should deal with hard-to-handle/edge cases and bogus user input (if there are any) gracefully.