Assignment 3, due Feb. 11

On every assignment, write your name legibly as it appears on your University ID and on the class list! Assignments are due at the start of class on the day indicated (usually Friday). Exceptions will be by advance arrangement unless there is what insurance companies call "an act of God" (something outside your control). Homework must be turned in on paper, either in class or in the teaching assistant's mailbox. Never push late work under someone's door!

1. Background: An assembler maps its input from one or more (source) files to an output (object) file by replacing various textual content in the input file(s), such as machine instruction names, with equivalent binary data such as the corresponding executable machine code. It allows textual names to be defined in terms of such things as machine addresses, and then it substitutes the actual addresses for those names.

   A linker maps its input from one or more (object) files to an output (executable) file by replacing various textual content in the input file(s), such as external symbol names, with equivalent binary data such as the corresponding external symbol values. It allows textual names to be defined in terms of such things as machine addresses, and then it substitutes the actual addresses for those names.

   A problem: (0.5 points) The above text suggests a strong parallel between what assemblers and linkers do. What (if anything) does an assembler do that a linker does not? What (if anything) does an linker do that an assembler does not? Focus on abstract functions!

2. Background: In the C standard library, FILE*s=fopen("myfile","r") opens a file named myfile for read access using the FILE pointer s. I can read successive characters of my file using ch=fgetc(s).

   The standard Unix system call int fd=open("myfile",O_RDONLY) opens a file named myfile for read access using the file descriptor fd. I can read successive characters of my file using read(fd,&ch,1)

   Obviously, the standard library layer is implemented in terms of the underlying Unix layer. System calls are inherently expensive, so the implementation of the C FILE abstraction makes an effort to call read infrequently using large buffers, so that calls to fgetc() usually simply get the next character from the buffer but occasionally call read() to get the next buffer.

   a) If performance were not an issue, give, in C a minimal representation for a C FILE variable, and give code for fgetc() written in terms of this minimal representation. Hint: This should involve writing trivial C code. (0.5 points)

   b) Suggest a reasonable reprsentation for a C FILE variable that supports the performance goals outlined above. (0.5 points)

   c) Give C code for fgetc() written in terms of your reasonable representation. (0.5 points)

3. Backgrount: The standard Unix file interface involves open(), read(), write(), lseek() and close(), as well as some more obscure routines that we will ignore here. There is nothing object oriented about the design of this interface, yet at a conceptual level, an open file is a perfect example of an object.

   A Problem: How is the handle on an open-file object in Unix represented? What is the creator-initializer for open-file objects? What are the methods on an open file object, and if one of these is a destructor method, which?