|
|
c m s c 311
s u m m e r 2 0 0 3 |
Due Thursday, June 19, 11:59 PM (just before midnight)
Posted: June 3, 2003
Learn to ask questions, if you have doubts.
No email project will be accepted. This means trying to avoid a late penalty despite "having it done" is not a valid excuse. You should attempt to submit something simple at least ONE day before the project is due to avoid such problems. You must submit the project using the submit command.
Please note that *all* programming projects in this course (including this one) are to be done independently or with the assistance of the instructional staff of this course only, unless otherwise specified IN PRINT by official webpages.
Please review the policies outlined on the class syllabus concerning the use of class computer accounts and concerning the University's Code of Academic Integrity. The instructors of this course will review the programs submitted by students for potential violations of the Code of Academic Integrity and if it is believed that a violation has occurred it will be referred to the Office of Judicial Programs and the Student Honor Council.
Hardcoding is considered a violation of academic integrity
To do this:
To change your finger information, type:
chfn
You should ONLY change your name. Please have your first
and last name as you are registered in the system. For example,
if you are registered as "Samir Khuller", please use "Samir Khuller"
rather than "Sammy Khuller" or "Biff Khuller", even if you prefer
to be called "Biff".
Ignore the parts that ask you for your phone number, office, etc. Just hit return, and don't fill anything in.
In addition, you will probably also want to change your password.
passwd
Notice the unusual spelling of "passwd".
This will ask for your original password, then your new password, and the new password again. If you use "ssh", it may take a day or so to take effect (it might work right away though). If you use "telnet", the changes should be immediate.
If you fail to change your name on your finger information, you will lose points on this project.
In this first project, one of the goals is to read and write binary files. You can do this in C or C++. The CMSC 114 text (by Deitel and Deitel) or books by Stanley Lippman (The C++ Primer) or Bjarne Stroustrup (C++ programming language) should explain about binary files. There may be resources on the web as well.
As you look up this information (try to look it up first, before just asking someone), try to keep the following in mind. "Poor" software can arise when you're goal is to merely get things to work. As you're trying to read/write binary files, try to play with several functions, and understand the various functions available to you.
Don't just find the first answer that works, and ignore the rest because it seems complicated. Often, making the initial attempt to learn the information "properly" will help you in the long run. You'll remember the answer better as well. If necessary, make a "quiz" question to help you remember how to write the code.
You can learn about reading and writing to binary files in several ways. You can find books on the subject. You can do a Web search (using, say, google.com). You can ask your friends (yes, reallY) to give you advice (but not code).
I don't particularly mind having you ask your friends, but here's the drawback. Employers tend to prefer employees can find out information on their own first, before asking. After all, if you have to ask everyone how to do things, then why are you needed? If other people have the answers, how valuable are you?
If you're concerned about "cheating", make sure you aren't showing anyone code that you plan to submit. It's better to go over examples from a book, or possibly the web, etc. If someone has to look at your code, and copy it down without thinking, that's crossing the line.
12 |
The question is trickier than you might imagine. Suppose you wrote a C++ program and stored the first value in this file into an int variable. What happens?
Let's answer the first question. What's in the file? When you edit a file using a text editor (as opposed to a word processor like Word which may store the text in a different format), you are editing ASCII.
Recall from your introductory C programming class that ASCII is an 8 bit representation for storing characters (actually, only the only 7 bits are "used"---the most significant bit is mostly ignored).
The ASCII code is a way to represent characters found on a typical American keyboard into an 8 bit binary code. Thus, when you type in '1' and '2', and save it to a file, you are really not saving '1' and '2' to a file.
Instead, you are saving the ASCII values of '1' and '2' to a file. The ASCII value for the character '1' is 49 (base 10), and for '2', it's 50 (base 10). Like everything with computers, what's really stored is the binary representation of 49 and 50 (which is "0011 0001" and "0011 0010", respectively). Thus, two bytes are saved in the text file.
Essentially, a text editor is a program which allows you to view the bytes of a file by translating the ASCII code into characters you can read. Thus, you don't see "1000 0001" on the text editor screen, you see 'A' (uppercase 'a').
There's an alternate way to save the number 12 to a file. Rather than store it as two ASCII characters (the characters '1' and '2' in the 8-bit ASCII representation), you can store it as a 4 byte binary value.
Recall that most 32 bit processors store int values using 4 bytes. The representation used is two's complement. Just as you can write two ASCII bytes '1' and '2' to a file, you can also write a 4 byte int value to a file as well.
In particular, if you looked at the hexadecimal representation of the file, you'd see "00 00 00 0c" (the spaces have been added to make it easier to read). 'c' is hexadecimal for 12.
Your first thought may be "why not use ASCII, it uses far fewer bytes?". That's true, at least, for the number 12. But what happens if you want to store the number 1000000 (one million). This would require 7 ASCII characters. However, one million can be represented as a signed int comfortably in 4 bytes.
Now what would happen if you read the file with a text editor? Would you see "0000000c"? Of course not! Recall that text editors view bytes in ASCII. So the first byte has ASCII value 0. ASCII value 0 is the null character. Depending on your editor, it may print nothing, or it may print ^@ (vim and emacs do this). It doesn't print 0, because the ASCII value of '0' is not 0, it's 48.
If the first byte stored 48 in binary, then you'd see '0' printed. Instead, the first byte stores 0, so it attempts to print out the ASCII character for this. Usually, this prints nothing.
Try the following program.
int main()
{
printf( "/%c/\n", (char) 0 ) ; // prints character with ASCII value 0
}
You should see "//". When it prints the character with ASCII
value 0, it actually prints nothing.
If you wrote:
int main()
{
printf( "/%c/\n", (char) 48 ) ; // prints character with ASCII value 48
}
This time, you see "/0/", because 48 is the ASCII code for the character '0'.
So, if you wrote the 4 byte quantity "0000000c", this represents 4 ASCII characters. It's the characters associated with ASCII value 0, 0, 0, and 12 (base 10). If you look up the characters with ASCII value 0 and 12, you will find they are non-printable characters, i.e., you can't see them on the screen when you print it.
Fortunately, editors such as vim and emacs notice such non-printable characters, and have ways of printing them out. Typically, they are printed with a carat, and some symbol after the character. Thus, you would see "^@^@^@^L". This is one way that editors let you know there's something besides spaces in the file (a space has ASCII value 32).
You may wonder why people use binary representation to store values. The reason is that it saves space. A 4 byte integer can store values up to 2 billion or so. To store a value of 2 billion in ASCII would require 10 bytes, instead of 4. Binary representation is very compact. The main drawback of binary representation is that you can't see the values easily with a text editor. It's not nearly as human readable.
In fact, all sorts of values can be stored this way. Floating point numbers (single precision) also use 4 bytes. Those 4 bytes can be written to a file. All objects require some number of bytes in memory. You can store objects in files as well, essentially by going byte by byte through the object (pretending it's a character array) and writing it to a file. By storing in this format, you save space, even though the file isn't really human readable (occasionally, the object might have a string in it, and you can see those printed as ASCII characters).
There are a variety of ways to implement a hex dump. The way you're going to do it is to read in a file into an array of characters. You will then need to treat each character as a hexadecimal value. This process will be explained in a separate specification to be provided soon.
In the meanwhile, try to think of how you might write such a utility.
This won't be a particularly difficult part of the project. The number of lines of code should be less than about 100 lines (should be far less, actually). The hardest part is locating the information you need to do this.
When the specs get posted, you'll get a better feel for how it should be implemented, but go ahead and figure out someway to do this in C/C++.
One intriguing aspect of writing a hex dump is that you can see the endian-ness. If I have an int variable, with 4 bytes, storing the value 12, then on a big endian machine, the hex dump will show "00 00 00 0c", and on a little endian machine, it will show "0c 00 00 00" (i.e., it's reversed).
As a point of reference, the detective cluster (which run Dec Alphas) is little endian, while WAM, which run Sun's are big endian (PCs, I believe, are little endian).