To practice manipulating binary data in a C program (for fun and glory).

With the UNIX people exploring binary data, and using hex editors, 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 binary data.

This project aims to ameliorate that.

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.

But: did you know that all text data is also binary data?

The trick to remember is that its opposite is not always true: not all binary data is text. In fact most of it isn't. Text represents is a very narrow range of possible data values, and then only within a certain context. You may “see” random letters when viewing binary data, but there is no continuity. The data values that we utilize when interacting with text are also valid combinations of binary values. Which can mean almost anything.

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.

Your task is to write a hex viewer and information highlighter, under the data theme of hard drive partition tables.

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 ~/src/cprog/cbf0/ directory already existing and ready to go, you can run the following commands:

lab46:~$ cp /var/public/spring2016/cprog/cbf0/*.mbr ~/src/cprog/cbf0/
lab46:~$ 

If you get a prompt back (no errors), then you were likely successful. Change into your project directory and begin work.

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:

Your program must:

• Require the user supply a file via the command-line
  • if the file specified does not exist/cannot be opened, display an error message and exit.
    • error message should be of the form: Error: Could not open 'filename' for reading!
      • Where filename is the name of the file specified on the command-line (make sure the quotes surround it in the output).
  • no further processing should be done if the file is not able to be accessed.
• Detect the current size of the terminal (see “Detecting Terminal Size” section below), and record the lines and columns into variables for use in your program.
  • 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!
    • Your program will only be displaying to an area 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.
    • 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).
• If a second command-line argument exists, assume it is a sizing throttle (controlling the number of lines your program will display). If no argument is given (or that argument is a 0), 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 after the header will display:
  • an 8-digit hex offset (with leading 0x indicator)
  • followed by a single space
  • then 4 single-spaced bytes of data
  • two spaces
  • another 4 single-spaced bytes of data, etc.
    • (for a total of 4 such columns, resulting in 16 total bytes being displayed per line).
  • Finally, two spaces after the last column, and:
  • a 16-character ASCII representation field (no separating spaces between the values)
    • all printable characters should be displayed.
    • all non-printable (and various whitespace) characters should be substituted with a '.'
  • No line will exceed 79 characters.
  • No line will be shorter than 79 characters.
  • A newline will be the character at position 80.
• Finally, another dashed heading line (this time a footer line) will be displayed, capping the output nicely.
• 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/footers)
  • 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; finish the current line (even if you have to pad spaces), display the corresponding ascii field (padding spaces as appropriate), and display the closing footer.
• Don't forget to fclose() any open file pointers! And free() any malloc()'ed or calloc()'ed memory.

To successfully complete this project, the following criteria must be met:

• Code must compile cleanly (no warnings or errors)
• Final image must be viewable.
• Code must be nicely and consistently indented (you may use the indent tool)
• Code must utilize the specifications presented above
• Code must be commented
  • have a properly filled-out comment banner at the top
  • have at least 20% of your program consist of //-style descriptive comments
• Track/version the source code in a repository
• Submit a copy of your source code to me using the submit tool.
  • You are to submit 3 files:
    • your C source code to accomplish this task
    • your copy of out.file
    • your processed cbf0.jpg file

To submit this program to me using the submit tool, run the following command at your lab46 prompt:

$ submit cprog cbf0 cbf0.c cbf0.file /home/username/public_html/cbf0.jpg
Submitting cprog project "cbf0":
    -> cbf0.c(OK)
    -> cbf0.file(OK)
    -> /home/username/public_html/cbf0.jpg(OK)

SUCCESSFULLY SUBMITTED

You should get some sort of confirmation indicating successful submission if all went according to plan. If not, check for typos and or locational mismatches.