/* The pixel type and an interface to pixels */

typedef int pixel; // Library (concrete) view of a pixel typedef pixel pixel_t; // Client (abstract) view of a pixel

// Returns the red component of the given pixel p. // POSTCONDITION: returned value is between 0 and 255, inclusive. int get_red(pixel p) {

}

// Returns the green component of the given pixel p. // POSTCONDITION: returned value is between 0 and 255, inclusive. int get_green(pixel p) {

}

// Returns the blue component of the given pixel p. // POSTCONDITION: returned value is between 0 and 255, inclusive. int get_blue(pixel p) {

}

// Returns the alpha component of the given pixel p. // POSTCONDITION: returned value is between 0 and 255, inclusive. int get_alpha(pixel p) {

}

// Returns an int representing an RGB pixel consisting of the given // alpha, red, green and blue intensity values. // PRECONDITION: all intensity values must be between 0 and 255, // inclusive. pixel make_pixel(int alpha, int red, int green, int blue) {

}

Second code:

/* The file pixel.c0 describes the pixel type. It also defines the * pixel interface with five functions: get_red(p), get_green(p), * get_blue(p), get_alpha(p), and make_pixel(a,r,g,b). If you're * *given* a working pixel implementation, you can use the pixel * interface without knowing which part of the integer is used to * store the blue intensity. You don't even need to know that pixels * are integers! * * When writing this file, only use the interface of pixel.c0. We'll * check your code by compiling and running it against different * implementations of the pixel interface, like the one you were given * in pixel-array.c0. * * There are 4 tasks in this file: * - 4 - Respecting interfaces * - 5 - Implement quantize() as described in the writeup * - 6 - Testing quantize() * - 7 - histogram() */

/* Task 4 - Respecting interfaces * * This implementation of the opacify() function takes a pixel and * return a pixel with alpha intensity 0xFF and with other intensities * unchanged. It does not currently respect the interface to pixels: * change it so that it does. */

pixel_t opacify(pixel_t p) { return 0xFF000000 || p; }

/* This is some code for testing the opacify() function. It *does* * respect the pixel interface. You can use it to test your * implementation and, if you want, extend it with your own tests, but * we won't run this test code in the autograder. */

bool opacify_works(pixel_t p1) { pixel_t p2 = opacify(p1); if (get_alpha(p2) != 0xFF) return false; if (get_red(p2) != get_red(p1)) return false; if (get_green(p2) != get_green(p1)) return false; if (get_blue(p2) != get_blue(p1)) return false; return true; }

void test_opacify() { assert(opacify_works(make_pixel(0xFF, 0x01, 0x03, 0x04))); assert(opacify_works(make_pixel(0x02, 0x00, 0xFF, 0xEE))); assert(opacify_works(make_pixel(0xFF, 0xFF, 0xFF, 0xFF))); assert(opacify_works(make_pixel(0x00, 0x00, 0x00, 0x00))); assert(opacify_works(make_pixel(0x00, 0xAA, 0xBB, 0xCC))); }

/* Task 5 - Implement quantize() as described in the writeup */

pixel_t quantize(pixel_t p, int q) //@requires 0

/* Task 6 - Testing quantize() * * Write some more tests for quantize. Remember to respect the pixels * interface! We *will* run these tests, and will grade them based on * their ability to catch buggy implementations of quantize. */

void test_quantize() { pixel_t p = quantize(make_pixel(0xFF, 0xFF, 0xFF, 0xFF), 4); assert(get_alpha(p) == 0xFF); assert(get_red(p) == 0xF0); assert(get_green(p) == 0xF0); assert(get_blue(p) == 0xF0); }

/* Task 7 - histogram() * * In C and C0, it's a bit difficult to return more than one value * from a function. For instance, say we needed to know, given an * array of pixels, how many pixels had average intensity 0, how many * pixels had average intensity 1, and so on, all the way to how many * many pixels had average intensity 255. * * We could write 256 different functions (!) to return these 256 * values, but what we'd like to do instead is write one loop that * calculates all 256 values. Then, those 256 values are returned * to the user by modifying the contents of an array that was passed * to the function. * * The function histogram is supposed to count the number of * pixels whose average intensity is i (a number between 0 and 255) * and store the results in results[i], where results is an array * of size 256. In other words, the pixel array A[] is an input and * should not change, but the integer array results[] is an output, * and we have to change it. * * The histogram function has a couple of bugs and therefore fails * the test cases below. Fix it, but do not change the interface. (You * shouldn't need to change the test cases, either.) */

void histogram(pixel_t[] A, int length, int[] results) //@requires \length(A) == length; //@requires \length(results) == 256; { results = alloc_array(int, 256);

for (int i = 0; i

/* This is some code for testing the histogram() function. You can * use it to help you understand what histogram is supposed to do, * and you can use it to test your implementation. If you want, you * can extend it with your own tests, but we won't run this test code * in the autograder. */

pixel_t[] copy_pixels(pixel_t[] A, int length) //@requires length == \length(A); //@ensures length == \length( esult); //@ensures esult != A; { pixel_t[] B = alloc_array(pixel_t, length); for (int i = 0; i

bool pixels_equal(pixel_t[] A, pixel_t[] B, int length) //@requires length == \length(A); //@requires length == \length(B); { for (int i = 0; i

void test_histogram() { pixel_t[] A; pixel_t[] C; int[] results = alloc_array(int, 256);

// Initialize the array of pixels, make a copy. A = alloc_array(pixel_t, 9); A[0] = make_pixel(0xFF, 0x01, 0x01, 0x01); A[1] = make_pixel(0x01, 0x00, 0xFF, 0xEE); A[2] = make_pixel(0xFF, 0xFF, 0xFF, 0xFF); A[3] = make_pixel(0xEE, 0xFF, 0xDD, 0x00); A[4] = make_pixel(0xDD, 0xCC, 0x00, 0xFF); A[5] = make_pixel(0xCC, 0x00, 0xDD, 0xEE); A[6] = make_pixel(0x00, 0xEE, 0xFF, 0xDD); A[7] = make_pixel(0x00, 0x00, 0x00, 0x00); A[8] = make_pixel(0x00, 0xDD, 0xCC, 0xBB); C = copy_pixels(A, 9);

// Compute the histogram and check the results histogram(A, 9, results); assert(pixels_equal(A, C, 9)); for (int i = 0; i

// Modify both arrays of pixels A[8] = make_pixel(0x00, 0x00, 0x00, 0xFF); C[8] = make_pixel(0x00, 0x00, 0x00, 0xFF);

// Compute the histogram and check the results count_zeroes(A, 9, results); assert(pixels_equal(A, C, 9)); for (int i = 0; i

typedef int[] pixel; // Library (concrete) view of a pixel typedef pixel pixel_t; // Client (abstract) view of a pixel

pixel make_pixel(int alpha, int red, int green, int blue) //Not including other contracts here as this is part of assignment //@ensures \length( esult) == 4; { pixel p = alloc_array(int, 4); p[0] = alpha; p[1] = red; p[2] = green; p[3] = blue; return p; }

int get_alpha(pixel p) //@requires \length(p) == 4; //Not including other contracts here as this is part of assignment { return p[0]; }

int get_red(pixel p) //@requires \length(p) == 4; //Not including other contracts here as this is part of assignment { return p[1]; }

int get_green(pixel p) //@requires \length(p) == 4; //Not including other contracts here as this is part of assignment { return p[2]; }

int get_blue(pixel p) //@requires \length(p) == 4; //Not including other contracts here as this is part of assignment { return p[3]; }

Fourth code:

/* Testing */

#use

int main() { test_opacify();

test_quantize();

test_histogram();

println("All tests passed!"); return 0; }

1 Pixels To capture the contents of a single pixel, we need to know two things: how opaque or transparent it is, and what color it is. One common way to do this is called ARGBU The transparency is stored as an integer in the range 0,256), where 0 is completely transparent and 255 is completely opaque. This is called the alpha (A) value. The color is stored as three other integers, each also in the range 0,256), which respectively describe the intensity of the red (R), green (G), and blue (B) color in the pixel. So a pixel is described by four numbers between 0 (inclusive) and 256 (exclusive) There are many ways to represent a pixel in a computer! One way to take the four numbers that make up a pixel and pack them inside a 32-bit CO int, breaking that int up into 4 components with 8 bits each: (041020344050607 7071727374757677 9091929394959697 bobbb3bbs.bgb7 where: (40010901314151607 represents the alpha value (how opaque the pixel is) TOP1727374757677 represents the intensity of the red component of the pixel 9091929394959697 represents the intensity of the green component of the pixel bobb2b3bb5b6by represents the intensity of the blue compofierit of the pixel Each 8-bit component can range between a minimum of (binary 00000000 or hex 0x00) to a maximum of 255 (binary 11111111 or hex OxFF). In the file pixel.co, right at the top we announce that we will be working with a type pixel that is actually represented as a single integer by writing a lype definition: typedef int pixel; The rest of the file should contain the implementation of an interface to the newly-defined pixel type (see Section B for what interfaces are exactly). By using this interface, we can manipulate pixels as four integers for red, green, blue, and alpha values instead of worrying exactly how they are packed into an integer- or even represented in in a totally different way. Complete the CO file pixel.co. Translate the English descriptions into code and the English contracts into CO contracts. You can load your completed file into coin. Remember to use the -d flag to check contracts. % coin -d pixel.co --> make pixel (255, 238, 127, 45); 2 Testing We can generally think about four ways that a program might fail: 1. Do something unsafe: access an array out of bounds, divide by zero, call a function with inputs that violate the function's preconditions. 2. Violate a loop invariant, an assertion, or a postcondition. 3. Return the wrong answer without violating any contracts. 4. Fail to terminate. For the fast exponent function we considered in lectures 1 and 2, failure #3 was impossible: the postcondition specified that exactly the right answer was returned. That won't always be the case, and it isn't the case for pixel.co. Make a copy of the pixel.co file named pixel-bad.co: % cp pixel.co pixel -bad.co Edit this file so that it contains a broken implementation of pixels. Keep the contracts the same, and avoid failures #1 and #4 - the program should remain safe and should terminate. However, at least one function should sometimes violate its postcondition (#2, a contract failure) and at least one function should sometimes give the wrong answer without violating a postcondition (#3, a contract exploit). Write a file pixel-test.co that checks for both contract failures and contract exploits in an implementation of the pixels interface. (See Appendix or the file puzzle-test.co distributed with the previous programming homework for an example of how to do this for the common-prefix function.) At minimum, the test should catch the bugs you made intentionally: % cce-W-d pixel.co pixel-test.co %./a.out %cco -W -d pixel-bad.ce pixel-test.co %./a.out make pixel (255, 238, 127, 45); 2 Testing We can generally think about four ways that a program might fail: 1. Do something unsafe: access an array out of bounds, divide by zero, call a function with inputs that violate the function's preconditions. 2. Violate a loop invariant, an assertion, or a postcondition. 3. Return the wrong answer without violating any contracts. 4. Fail to terminate. For the fast exponent function we considered in lectures 1 and 2, failure #3 was impossible: the postcondition specified that exactly the right answer was returned. That won't always be the case, and it isn't the case for pixel.co. Make a copy of the pixel.co file named pixel-bad.co: % cp pixel.co pixel -bad.co Edit this file so that it contains a broken implementation of pixels. Keep the contracts the same, and avoid failures #1 and #4 - the program should remain safe and should terminate. However, at least one function should sometimes violate its postcondition (#2, a contract failure) and at least one function should sometimes give the wrong answer without violating a postcondition (#3, a contract exploit). Write a file pixel-test.co that checks for both contract failures and contract exploits in an implementation of the pixels interface. (See Appendix or the file puzzle-test.co distributed with the previous programming homework for an example of how to do this for the common-prefix function.) At minimum, the test should catch the bugs you made intentionally: % cce-W-d pixel.co pixel-test.co %./a.out %cco -W -d pixel-bad.ce pixel-test.co %./a.out