This shows you the differences between two versions of the page.
Next revision | Previous revision | ||
haas:fall2017:cprog:projects:cbf0 [2016/03/22 19:56] – external edit 127.0.0.1 | haas:fall2017:cprog:projects:cbf0 [2017/10/15 20:49] (current) – wedge | ||
---|---|---|---|
Line 3: | Line 3: | ||
< | < | ||
</ | </ | ||
- | |||
- | ~~TOC~~ | ||
======Project: | ======Project: | ||
Line 12: | Line 10: | ||
=====Background===== | =====Background===== | ||
- | With the UNIX people exploring | + | We've had a newfound exposure to data this semester, and how programming languages like C interpret different forms of data; we look at things like data type and corresponding storage allocated, and we use these as ingredients in our programmatic solutions. |
+ | |||
+ | Yet- we've also inserted a layer of abstraction between us and the computer: integers and floating point values and ASCII characters... each with its own unique ways of accessing and manipulating. | ||
+ | |||
+ | The thing is: to the computer all data is largely the same: sequences of 1s and 0s, accessed in units of bytes. | ||
+ | |||
+ | This project will expose us to some of the underlying aspects of the realm of data that lies closer to the computer, that of "binary data", where we often come in contact with hexadecimal values to aid us in the interaction. | ||
+ | |||
+ | So, as we are here to learn more about the computer, it only makes sense to steer some of our activities towards the manipulation of binary data as well- one cannot effectively solve a whole domain of problems if they have no idea how to work with it. | ||
This project aims to ameliorate that. | This project aims to ameliorate that. | ||
Line 18: | Line 24: | ||
Binary data merely refers to data as the computer stores it. The computer is a binary device, so its raw data (as it exists on various forms of storage and media) is often referred to as binary data, to reflect the 1s and 0s being represented. | Binary data merely refers to data as the computer stores it. The computer is a binary device, so its raw data (as it exists on various forms of storage and media) is often referred to as binary data, to reflect the 1s and 0s being represented. | ||
- | The data we have become familiar with is textual data. We read from and write to files with the express purpose of storing text in them. And with the use of various text processing tools, we can easily manipulate these text files. | + | The data we have become familiar with is textual data. We read from and write to files (even with those files commonly being the keyboard and screen) |
But: did you know that all text data is also binary data? | But: did you know that all text data is also binary data? | ||
Line 26: | Line 32: | ||
So, text is really ONE (of many) possible representations of binary data. We need to gain a wider perspective and get more familiar with this more expansive and general notion of binary data. | So, text is really ONE (of many) possible representations of binary data. We need to gain a wider perspective and get more familiar with this more expansive and general notion of binary data. | ||
- | The computer works in units of **bytes**, which these days means groups of 8-bits. C has the ability to arbitrarily read and write individual bytes of data, and we will want to make use of that to aid us in our current task. | + | The computer works in units of **bytes**, which these days means groups of 8 bits. C has the ability to arbitrarily read and write individual bytes of data, and we will want to make use of that to aid us in our current task. |
+ | |||
+ | =====Opening and reading from files===== | ||
+ | The nice thing about C is that it tends to embody the " | ||
+ | |||
+ | What this means, basically, is that interacting with data in a file is really no different that interacting with data from the keyboard or data to the screen. We merely need a FILE pointer and appropriate resources allocated. | ||
+ | |||
+ | To interact with a file, we must first declare a pointer to type FILE that will be our point of transaction. | ||
+ | |||
+ | Common names for our file pointer variable are **fp**, **fPtr**, **input**, **inp**, but in reality can be anything you want. | ||
+ | |||
+ | The intention is that, of course, you name variables so they are meaningful in the context of the overall implementation. | ||
+ | |||
+ | <code c> | ||
+ | FILE *input | ||
+ | </ | ||
+ | |||
+ | ====Opening a file with fopen()==== | ||
+ | To attach a file stream to a FILE pointer, we utilize a file opening function such as **fopen()**. | ||
+ | |||
+ | It takes two arguments: | ||
+ | - the path and name of file we wish to open (provided as a string) | ||
+ | - the mode we wish to open the file as (provided as a string) | ||
+ | |||
+ | There are 3 common file opening modes (and combinations thereof, among others, sometimes dependent on the particular operating system being run). For now, I highly recommend just sticking to ONE mode of operation per FILE pointer. This can avoid messy things like data corruption and indirect logic/ | ||
+ | |||
+ | The 3 file modes: | ||
+ | * r - open file for reading (start at beginning) | ||
+ | * w - open file for writing (start at beginning) | ||
+ | * a - open file for appending (add to end) | ||
+ | |||
+ | If we wanted to open the file " | ||
+ | |||
+ | <code c> | ||
+ | input = fopen (" | ||
+ | </ | ||
+ | |||
+ | Note the double quotes around each argument. They both need to be strings (ie array of char terminated with NULL terminator characters), | ||
+ | |||
+ | ====Reading from the file==== | ||
+ | If the file is filled with a set format of data you'd like to retrieve, such as one short integer per line (basically, a text file filled with numbers), we can just use our trusty and familiar **fscanf()** function. We merely have have to indicate the correct file pointer: | ||
+ | |||
+ | <code c> | ||
+ | short int value = 0; | ||
+ | |||
+ | ... | ||
+ | |||
+ | fscanf (input, " | ||
+ | </ | ||
+ | |||
+ | If there is no simple universal " | ||
+ | |||
+ | The **fscanf()** function is still viable here, but if all we're after is a char value, there' | ||
+ | |||
+ | To read a byte of data from a file and store it in our variable (called byte), we would do the following: | ||
+ | |||
+ | <code c> | ||
+ | char byte = 0; | ||
+ | |||
+ | ... | ||
+ | |||
+ | byte = fgetc (input); | ||
+ | </ | ||
+ | |||
+ | The **fgetc()** function takes the intended FILE pointer it is to read from as its argument, so **input** should be a FILE pointer AND should have previously been **fopen()**' | ||
+ | |||
+ | To make things easier, placing logic to read from a file in a loop can be a very powerful combination. | ||
=====Task===== | =====Task===== | ||
- | Your task is to write a hex viewer | + | Your task is to write a hex viewer, |
- | On lab46, in the **cbf0/** subdirectory of the CPROG Public Directory, are a number of files ending in a **.mbr**; most are copies of Master Boot Records (MBRs) from various installed Operating Systems (so real, actual data). | ||
- | Please copy these files into a working directory for your **cbf0** endeavors. Assuming you have a **~/ | + | =====Experiencing xxd===== |
+ | If we don't know what it is we are implementing, | ||
<cli> | <cli> | ||
- | lab46:~$ cp /var/ | + | lab46:~/src/cprog/cbf0$ cat sample0.txt |
- | lab46:~$ | + | > |
+ | [abcdefghijklmnopqrstuvwxyz] | ||
+ | 01: BINARY | ||
+ | 01234567: | ||
+ | 0123456789: | ||
+ | 0123456789ABCDEF: | ||
+ | )!@# | ||
+ | . | ||
+ | lab46:~/ | ||
</ | </ | ||
- | If you get a prompt back (no errors), then you were likely successful. Change into your project directory and begin work. | + | Note how it is filled with ASCII text- many of our recognizable symbols we use when using a text editor. |
- | Your task is to write a C program that takes a file name as a command-line argument, opens that file, reads its contents, and displays that data (in hex) to the screen according to various criteria: | + | But, to illustrate how text is just a form of binary, witness what we are shown when we peel away a layer, and view the binary data (represented in hex for convenience) of that same file: |
+ | |||
+ | < | ||
+ | lab46: | ||
+ | 0000000: 3e41 4243 4445 4647 4849 4a4b 4c4d 4e4f > | ||
+ | 0000010: 5051 5253 5455 5657 5859 5a3c 0a5b 6162 PQRSTUVWXYZ< | ||
+ | 0000020: 6364 6566 6768 696a 6b6c 6d6e 6f70 7172 cdefghijklmnopqr | ||
+ | 0000030: 7374 7576 7778 797a 5d0a 3031 3a09 0920 stuvwxyz].01: | ||
+ | 0000040: 4249 4e41 5259 0a30 3132 3334 3536 373a BINARY.01234567: | ||
+ | 0000050: 0920 4f43 5441 4c0a 3031 3233 3435 3637 . OCTAL.01234567 | ||
+ | 0000060: 3839 3a09 2044 4543 494d 414c 0a30 3132 89:. DECIMAL.012 | ||
+ | 0000070: 3334 3536 3738 3941 4243 4445 463a 4845 3456789ABCDEF: | ||
+ | 0000080: 5841 4445 4349 4d41 4c0a 2921 4023 2425 XADECIMAL.)!@# | ||
+ | 0000090: 5e26 2a28 0a2e 0a ^& | ||
+ | lab46: | ||
+ | </ | ||
+ | |||
+ | The EXACT same file, with the EXACT same arrangement of data, only represented more as the computer looks at it (sequentially, | ||
+ | |||
+ | The output of **xxd(1)** has 3 distinct sections: | ||
+ | - the address or offset (from the start of file). This is a hexadecimal address, starting at 0 (beginning of the file), and increments according to the number of bytes displayed. You'll notice that there are (at maximum) the same number of bytes on each line, so the offset increments by that amount with each new line it displays. | ||
+ | - the actual data (represented in hex); here we see 8 columns of hex values, grouped together in pairs of two bytes (other hex viewers may separate into 16 columns, isolating each byte for better viewing). | ||
+ | - the ASCII rendering (far right field); if we are viewing an ASCII file, we will easily see the ASCII contents of this file. If we are viewing a non-ASCII file, we may still see random ASCII values, but that is just that the value stored in the particular byte maps to that ASCII value, and should NOT be considered actual ASCII data. | ||
+ | |||
+ | This is one of those conceptual roadblocks many develop- they think that binary is somehow more complicated than it is, and create all sorts of obstacles to effective access. Here we will try to break down some of those walls, because this is really important stuff to know. | ||
+ | |||
+ | Your task is to write a C program that takes a file name as a command-line argument, opens that file, reads its contents, and displays that data to the screen in the manner that the **xxd(1)** tool does in the above example (note that while the **xxd(1)** tool has other features, we are not looking | ||
Your program must: | Your program must: | ||
Line 53: | Line 160: | ||
* If the terminal your program is being run in is **less than** 80 columns, display an error message and exit. | * If the terminal your program is being run in is **less than** 80 columns, display an error message and exit. | ||
* error message should be of the form: **Error: Terminal width is less than 80 columns!** | * error message should be of the form: **Error: Terminal width is less than 80 columns!** | ||
- | * Your program will only be displaying to an area 80 characters wide, so a wider terminal will not influence program output. | + | * Your program will only be displaying to an area up to 80 characters wide, so a wider terminal will not influence program output. |
* Similarly, if the number of lines in the terminal is **less than** 20, display a similar error message and exit. | * Similarly, if the number of lines in the terminal is **less than** 20, display a similar error message and exit. | ||
* error message should be of the form: **Error: Terminal height is less than 20 lines!** | * error message should be of the form: **Error: Terminal height is less than 20 lines!** | ||
* Unlike the width, the height can impact program output (taller terminals, if not otherwise throttled by a second command-line argument, can auto-expand if there is more room and data to display). | * Unlike the width, the height can impact program output (taller terminals, if not otherwise throttled by a second command-line argument, can auto-expand if there is more room and data to display). | ||
- | * The second command-line argument is a sizing throttle (controlling the number of lines your program will display). If a **0** is given, assume autosize (use the detected height to be your maximum in your calculations). | + | * The second command-line argument is a sizing throttle (controlling the number of lines your program will display). If no argument, or a **0** is given, assume autosize (use the detected height to be your maximum in your calculations). |
- | * Display an ASCII header identifying the various fields (offset, hex, ascii), surrounded by dashed lines, running 79 characters in width. See below for more details. | + | * Each row will display: |
- | * Each row after the header | + | * a 7-digit hex offset (referring to the first data byte on a given line) |
- | * an 8-digit hex offset (with leading **0x** indicator) | + | * followed by a colon and a single space |
- | * followed by a single space | + | * differently from **xxd(1)**: sixteen space separated groups |
- | * then 4 single-spaced bytes of data | + | * however you arrive at it: two total spaces |
- | | + | |
- | | + | |
- | | + | |
- | * Finally, | + | |
* a 16-character ASCII representation field (no separating spaces between the values) | * a 16-character ASCII representation field (no separating spaces between the values) | ||
* all printable characters should be displayed. | * all printable characters should be displayed. | ||
* all non-printable (and various whitespace) characters should be substituted with a ' | * all non-printable (and various whitespace) characters should be substituted with a ' | ||
- | | + | * A newline will be the last character |
- | * No line will be shorter than 79 characters. | + | * The hex values and rendered ASCII displayed will be sourced from the file specified on the command-line. While the target files for this project are less than 512 bytes, your program should be able to handle larger and smaller files, and update its display accordingly. |
- | | + | * If a line throttle is given, your program is to stop output of data and ASCII rendering at that line, once it completes. |
- | * Finally, another dashed heading | + | * Once the data in the file has been exhausted, you need to wrap up as appropriate; |
- | * The hex values and rendered ASCII displayed will be sourced from the file specified on the command-line. While the target files for this project are all 512 bytes, your program should be able to handle larger and smaller files, and update its display accordingly. | + | |
- | * If a line throttle is given, your program is to stop output of data and display the terminating footer (to be included to the line count, just as the header is, so that means 4 lines are allocated for headers/ | + | |
- | * on a 20 character tall terminal, this would leave 16 lines for data display, which would result in a total of 256 bytes being displayed (offsets 0x00 - 0xff). | + | |
- | * Once the data in the file has been exhausted, you need to wrap up as appropriate; | + | |
* Don't forget to **fclose()** any open file pointers! And **free()** any **malloc()**' | * Don't forget to **fclose()** any open file pointers! And **free()** any **malloc()**' | ||
+ | Sample output of your program should be as follows (compared to the **xxd(1)** output above): | ||
+ | |||
+ | <cli> | ||
+ | 0000000: 3e 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f > | ||
+ | 0000010: 50 51 52 53 54 55 56 57 58 59 5a 3c 0a 5b 61 62 PQRSTUVWXYZ< | ||
+ | 0000020: 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 cdefghijklmnopqr | ||
+ | 0000030: 73 74 75 76 77 78 79 7a 5d 0a 30 31 3a 09 09 20 stuvwxyz].01: | ||
+ | 0000040: 42 49 4e 41 52 59 0a 30 31 32 33 34 35 36 37 3a BINARY.01234567: | ||
+ | 0000050: 09 20 4f 43 54 41 4c 0a 30 31 32 33 34 35 36 37 . OCTAL.01234567 | ||
+ | 0000060: 38 39 3a 09 20 44 45 43 49 4d 41 4c 0a 30 31 32 89:. DECIMAL.012 | ||
+ | 0000070: 33 34 35 36 37 38 39 41 42 43 44 45 46 3a 48 45 3456789ABCDEF: | ||
+ | 0000080: 58 41 44 45 43 49 4d 41 4c 0a 29 21 40 23 24 25 XADECIMAL.)!@# | ||
+ | 0000090: 5e 26 2a 28 0a 2e 0a | ||
+ | </ | ||
=====Detecting Terminal Size===== | =====Detecting Terminal Size===== | ||
- | To detect the current size of your terminal, you may make use of the following code (provided in the form of a complete program for you to test, and then adapt into your code as appropriate): | + | To detect the current size of your terminal, you may make use of the following code, provided in the form of a complete program for you to test, and then adapt into your code as appropriate. |
+ | |||
+ | It makes use of a **structure**, | ||
<code c> | <code c> | ||
- | #include < | ||
#include < | #include < | ||
+ | #include < | ||
+ | #include < | ||
int main (void) | int main (void) | ||
Line 98: | Line 214: | ||
</ | </ | ||
- | An **ioctl(2)** is a method (and system/ | + | An **ioctl(2)** is a method (and system/ |
Here we are accessing the information on our terminal file, retrieving the width and height so that we can make use of them productively in our programs. | Here we are accessing the information on our terminal file, retrieving the width and height so that we can make use of them productively in our programs. | ||
Line 104: | Line 220: | ||
Compile and run the above code to see how it works. Try it in different size terminals. Then incorporate the logic into your hex viewer for this project. | Compile and run the above code to see how it works. Try it in different size terminals. Then incorporate the logic into your hex viewer for this project. | ||
- | =====Example output===== | ||
- | When running the program, its output should match the following examples **precisely** (I'll be evaluating in part on the exactness of it matching my version). | ||
- | |||
- | ====Unthrottled display (512 bytes)==== | ||
- | |||
- | <cli> | ||
- | lab46: | ||
- | ------------------------------------------------------------------------------- | ||
- | offset | ||
- | ------------------------------------------------------------------------------- | ||
- | 0x00000000 33 c0 8e d0 bc 00 7c 8e c0 8e d8 be 00 7c bf 00 3.....|......|.. | ||
- | 0x00000010 06 b9 00 02 fc f3 a4 50 68 1c 06 cb fb b9 04 00 .......Ph....... | ||
- | 0x00000020 bd be 07 80 7e 00 00 7c 0b 0f 85 0e 01 83 c5 10 ....~..|........ | ||
- | 0x00000030 e2 f1 cd 18 88 56 00 55 c6 46 11 05 c6 46 10 00 .....V.U.F...F.. | ||
- | 0x00000040 b4 41 bb aa 55 cd 13 5d 72 0f 81 fb 55 aa 75 09 .A..U..]r...U.u. | ||
- | 0x00000050 f7 c1 01 00 74 03 fe 46 10 66 60 80 7e 10 00 74 ....t..F.f`.~..t | ||
- | 0x00000060 26 66 68 00 00 00 00 66 ff 76 08 68 00 00 68 00 & | ||
- | 0x00000070 7c 68 01 00 68 10 00 b4 42 8a 56 00 8b f4 cd 13 |h..h...B.V..... | ||
- | 0x00000080 9f 83 c4 10 9e eb 14 b8 01 02 bb 00 7c 8a 56 00 ............|.V. | ||
- | 0x00000090 8a 76 01 8a 4e 02 8a 6e 03 cd 13 66 61 73 1c fe .v..N..n...fas.. | ||
- | 0x000000a0 4e 11 75 0c 80 7e 00 80 0f 84 8a 00 b2 80 eb 84 N.u..~.......... | ||
- | 0x000000b0 55 32 e4 8a 56 00 cd 13 5d eb 9e 81 3e fe 7d 55 U2..V...]...> | ||
- | 0x000000c0 aa 75 6e ff 76 00 e8 8d 00 75 17 fa b0 d1 e6 64 .un.v....u.....d | ||
- | 0x000000d0 e8 83 00 b0 df e6 60 e8 7c 00 b0 ff e6 64 e8 75 ......`.|....d.u | ||
- | 0x000000e0 00 fb b8 00 bb cd 1a 66 23 c0 75 3b 66 81 fb 54 .......f# | ||
- | 0x000000f0 43 50 41 75 32 81 f9 02 01 72 2c 66 68 07 bb 00 CPAu2....r, | ||
- | 0x00000100 00 66 68 00 02 00 00 66 68 08 00 00 00 66 53 66 .fh....fh....fSf | ||
- | 0x00000110 53 66 55 66 68 00 00 00 00 66 68 00 7c 00 00 66 SfUfh....fh.|..f | ||
- | 0x00000120 61 68 00 00 07 cd 1a 5a 32 f6 ea 00 7c 00 00 cd ah.....Z2...|... | ||
- | 0x00000130 18 a0 b7 07 eb 08 a0 b6 07 eb 03 a0 b5 07 32 e4 ..............2. | ||
- | 0x00000140 05 00 07 8b f0 ac 3c 00 74 09 bb 07 00 b4 0e cd ......< | ||
- | 0x00000150 10 eb f2 f4 eb fd 2b c9 e4 64 eb 00 24 02 e0 f8 ......+..d..$... | ||
- | 0x00000160 24 02 c3 49 6e 76 61 6c 69 64 20 70 61 72 74 69 $..Invalid parti | ||
- | 0x00000170 74 69 6f 6e 20 74 61 62 6c 65 00 45 72 72 6f 72 tion table.Error | ||
- | 0x00000180 20 6c 6f 61 64 69 6e 67 20 6f 70 65 72 61 74 69 | ||
- | 0x00000190 6e 67 20 73 79 73 74 65 6d 00 4d 69 73 73 69 6e ng system.Missin | ||
- | 0x000001a0 67 20 6f 70 65 72 61 74 69 6e 67 20 73 79 73 74 g operating syst | ||
- | 0x000001b0 65 6d 00 00 00 63 7b 9a 98 a8 b3 d9 00 00 80 01 em...c{......... | ||
- | 0x000001c0 01 00 0b 7f 3f 03 3f 00 00 00 c1 7d 00 00 00 00 ....? | ||
- | 0x000001d0 01 04 07 6d ed df 00 7e 00 00 80 8d 79 00 00 00 ...m...~....y... | ||
- | 0x000001e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ | ||
- | 0x000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa ..............U. | ||
- | ------------------------------------------------------------------------------- | ||
- | lab46: | ||
- | </ | ||
- | |||
- | ====20 line Throttled display (on a file of 512 bytes)==== | ||
- | |||
- | Here we force our program to cut output short, with a 20 line display cap (note: 4 lines for header/ | ||
- | |||
- | <cli> | ||
- | lab46: | ||
- | ------------------------------------------------------------------------------- | ||
- | offset | ||
- | ------------------------------------------------------------------------------- | ||
- | 0x00000000 eb 3c 90 4f 70 65 6e 42 53 44 00 00 02 02 00 00 .< | ||
- | 0x00000010 00 00 00 00 00 f8 00 00 00 00 00 00 10 00 00 00 ................ | ||
- | 0x00000020 00 00 00 00 00 00 29 00 00 00 00 55 4e 49 58 20 ......)....UNIX | ||
- | 0x00000030 4c 41 42 45 4c 55 46 53 20 34 2e 34 00 00 ea 48 LABELUFS 4.4...H | ||
- | 0x00000040 00 c0 07 b0 58 e9 37 01 31 c0 8e d0 bc fc 7b 0e ....X.7.1.....{. | ||
- | 0x00000050 1f be e4 01 88 d6 b4 02 cd 16 0c 00 a8 03 74 03 ..............t. | ||
- | 0x00000060 4e 30 f6 e8 56 01 f6 c6 80 74 1e 52 bb aa 55 b4 N0..V....t.R..U. | ||
- | 0x00000070 41 cd 13 5a 72 13 81 fb 55 aa 75 0d f6 c1 01 74 A..Zr...U.u....t | ||
- | 0x00000080 08 c7 06 d1 01 84 01 eb 1a 52 b4 08 cd 13 72 b3 .........R....r. | ||
- | 0x00000090 88 36 55 01 80 e1 3f 74 aa 88 0e 4c 01 b0 3b e8 .6U...? | ||
- | 0x000000a0 25 01 5a 66 b8 18 00 00 00 bb e0 07 ff 16 d1 01 %.Zf............ | ||
- | 0x000000b0 66 be 28 06 00 00 bf 03 00 89 f9 83 f9 0c 72 03 f.(...........r. | ||
- | 0x000000c0 b9 0c 00 bb 00 40 b0 2e e8 fc 00 fc 66 ad 66 60 .....@......f.f` | ||
- | 0x000000d0 ff 16 d1 01 66 61 81 c3 00 04 4f e2 e9 09 ff 74 ....fa....O....t | ||
- | 0x000000e0 22 b8 49 00 08 e4 0f 85 95 00 fe 06 e3 00 66 ad " | ||
- | 0x000000f0 53 bb e0 07 ff 16 d1 01 5b 66 be 00 02 00 00 89 S.......[f...... | ||
- | ------------------------------------------------------------------------------- | ||
- | lab46: | ||
- | </ | ||
- | |||
- | ====30 line throttled display (on a 217 byte file)==== | ||
- | |||
- | This example demonstrates the scenario where there isn't enough data to complete not only the specified number of lines, but not even the line it was displaying. In such a case, we pad the line with spaces out to the end (both data and ascii fields) so that everything lines up (note the display of the ascii for whatever data was present on the line). | ||
- | |||
- | <cli> | ||
- | lab46: | ||
- | ------------------------------------------------------------------------------- | ||
- | offset | ||
- | ------------------------------------------------------------------------------- | ||
- | 0x00000000 eb 63 90 10 8e d0 bc 00 b0 b8 00 00 8e d8 8e c0 .c.............. | ||
- | 0x00000010 fb be 00 7c bf 00 06 b9 00 02 f3 a4 ea 21 06 00 ...|.........!.. | ||
- | 0x00000020 00 be be 07 38 04 75 0b 83 c6 10 81 fe fe 07 75 ....8.u........u | ||
- | 0x00000030 f3 eb 16 b4 02 b0 01 bb 00 7c b2 80 8a 74 01 8b .........|...t.. | ||
- | 0x00000040 4c 02 cd 13 ea 00 7c 00 00 eb fe 00 00 00 00 00 L.....|......... | ||
- | 0x00000050 00 00 00 00 00 00 00 00 00 00 00 80 01 00 00 00 ................ | ||
- | 0x00000060 00 00 00 00 ff fa eb 07 f6 c2 80 75 02 b2 80 ea ...........u.... | ||
- | 0x00000070 74 7c 00 00 31 c0 8e d8 8e d0 bc 00 20 fb a0 64 t|..1....... ..d | ||
- | 0x00000080 7c 3c ff 74 02 88 c2 52 be 80 7d e8 1c 01 be 05 |< | ||
- | 0x00000090 7c f6 c2 80 74 48 b4 41 bb aa 55 cd 13 5a 52 72 |...tH.A..U..ZRr | ||
- | 0x000000a0 3d 81 fb 55 aa 75 37 83 e1 01 74 32 31 c0 89 44 =..U.u7...t21..D | ||
- | 0x000000b0 04 40 88 44 ff 89 44 02 c7 04 10 00 66 8b 1e 5c .@.D..D.....f..\ | ||
- | 0x000000c0 7c 66 89 5c 08 66 8b 1e 60 7c 66 89 5c 0c c7 44 |f.\.f..`|f.\..D | ||
- | 0x000000d0 06 00 70 b4 42 cd 13 72 05 ..p.B..r. | ||
- | ------------------------------------------------------------------------------- | ||
- | lab46: | ||
- | </ | ||
- | |||
- | =====Bonus Opportunities===== | ||
- | The following can be considered a bonus point opportunity: | ||
- | |||
- | * Enhance the program to accept up to 6 pairs of additional values (offset followed by its length), where each offset through length will be colored using ANSI text escape sequences. | ||
- | * For any line containing this colorized text, highlight the address in bold white. | ||
- | |||
- | ====Sample output==== | ||
- | |||
- | As an example, running the program with the following arguments could produce results like this: | ||
- | |||
- | <cli> | ||
- | lab46: | ||
- | </ | ||
- | |||
- | {{: | ||
- | ====ANSI escape sequences for color==== | ||
- | This probably isn't very portable, and depending on the terminal, it may not work for some people. | ||
- | |||
- | It may be most convenient to set up preprocessor #define statements near the top of your code, as follows: | ||
- | |||
- | <code c> | ||
- | # | ||
- | # | ||
- | # | ||
- | # | ||
- | # | ||
- | # | ||
- | # | ||
- | # | ||
- | # | ||
- | # | ||
- | # | ||
- | # | ||
- | # | ||
- | # | ||
- | # | ||
- | # | ||
- | # | ||
- | # | ||
- | </ | ||
- | |||
- | To use, you output them: | ||
- | |||
- | < | ||
- | fprintf(stdout, | ||
- | fprintf(stdout, | ||
- | fprintf(stdout, | ||
- | </ | ||
- | |||
- | You have to remember to turn the color or setting off (resetting it) to revert back to the original color. | ||
- | |||
- | You can mix and match as well: | ||
- | |||
- | < | ||
- | fprintf(stdout, | ||
- | fprintf(stdout, | ||
- | fprintf(stdout, | ||
- | fprintf(stdout, | ||
- | fprintf(stdout, | ||
- | </ | ||
- | |||
- | While there are 8 available foreground colors, bolding can double that range to 16. | ||
=====Submission===== | =====Submission===== | ||
To successfully complete this project, the following criteria must be met: | To successfully complete this project, the following criteria must be met: | ||
* Code must compile cleanly (no warnings or errors) | * Code must compile cleanly (no warnings or errors) | ||
- | * Use the **-Wall** | + | * Use the **-Wall** |
* Code must be nicely and consistently indented (you may use the **indent** tool) | * Code must be nicely and consistently indented (you may use the **indent** tool) | ||
* Code must utilize the algorithm/ | * Code must utilize the algorithm/ | ||
* Output **must** match the specifications presented above (when given the same inputs) | * Output **must** match the specifications presented above (when given the same inputs) | ||
* Code must be commented | * Code must be commented | ||
- | * have a properly filled-out comment banner at the top | + | * be sure your comments reflect |
- | | + | |
* Track/ | * Track/ | ||
* Submit a copy of your source code to me using the **submit** tool. | * Submit a copy of your source code to me using the **submit** tool. |