unix and Linux project

1. Studying a Program
By the time P2 is due, we would have covered the essentials of our File Sys project. The tar ball source.tbz is a collection of files given so that (i) you can get started quickly with our project, and (ii) you can see the style of how larger systems programs are written. Download source.tbz from the link above. In the OSIS Lab, it can be un-tar-ed as follows: tar xvvfj source.tbz

The functionality of source.tbz is described in What Is Given. Some details of the code are/were explained in the lectures and in ReadMe.txt. Study the provided source code so thoroughly that you could have written it. Then, answer the itemized questions below in a file named answers.txt.

The following are standard library routines:
fopen, fclose, fread, fwrite, fstat, fscanf, fprintf, sprintf
Look up their functionality in both the Stevens' book and the on-line man pages. Describe their functionality briefly, one sentence each, in your own words.
List the names of 5 standard library routines other than the above, and 5 system calls used by the code of P2.
In the file simDisk.C, what is the point in verifying that statBuf.st_size == nSectorsPerDisk * nBytesPerSector?
Study the Notes on Programming in C, by Rob Pike. All of it is "very" applicable to C++ also. For five identifiers used in the given source code, (i) either suggest better alternate names and defend why they are better, or (ii) explain why you are comfortable with the names as-they-are.
Write the pre- post conditions for
uint FileVolume::read33file(byte *fs33leaf, byte *unixFilePath)
uint FileVolume::write33file(byte *unixFilePath, byte *fs33leaf)
2. Learn to Use GDB
Coming into the course, you are expected to be comfortable with gdb. Debugging large programs requires the construction of (extra) observer methods. Using gdb or some other debugger is not as effective as invoking observers and studying their output in a peaceful place ("under a tree"). Nevertheless, gdb can be useful as a last resort, and you must be able to use it well.
Start script. Make P2 as given. Run our program P2 through gdb.
Set a breakpoint at immediately after setArgsGiven(buf, arg, types, nMax); Examine the values of buf, arg, types, nMax.
Type in a command to our shell to make a file volume. Trace the execution from the above breakpoint onwards by single stepping until after simDisk is initialized in mkSimDisk().
Set a breakpoint at the bottom of the SimDisk constructor. Examine the value of diskName.
Type in a wrdisk request followed by a rddisk. Verify that the results match.
End the script. Turn in this script as a file named gdbSession.txt
3. Additions and Improvements
Part of large program development is independently, but wisely, deciding what to do for certain "erroneous" situations. Should we ask the professor for what to do for every possible error you can think of? [Answer: No. You think about it. You take a reasonable action. You document this in your source code, and in ReadMe.txt. And, be ready to defend your choice should it be questioned.] Should SimDisk() constructor printf or cout>> an error message? [No.] When does/should mkSimDisk() return a zero? [Think.] Remember that one of the goals of CEG 433/633 is to make you think about larger programs. Part of this is to supply missing, but needed, details in the problem description.