This library implements a rudimentary stand-alone stdio package. More
information may be found in the file DOC.

All "standard" SYSV file I/O routines are implemented (see stdio.h)
though with the following:

MAJOR CAVEATS:

1. File names have been substituted for starting block numbers. For example:
	..
	FILE *foo;
	foo = fopen(10, "rw");
	..

   Would open a file read/write starting at disk block 10.

2. Files are essentially endless, though the user can define some magic
   byte denoting the "end" or simply always know how much to read for a given
   file. Using a byte-size EOF probably only makes sense for stdin, where it
   is automatically defined as ^D (though this can be disabled). Since EOF
   is nothing more than a magic cookie of sorts, the user is allowed to read
   past it with no ill effects. Another side effect of endless files is that
   every file assumes it owns all space between its starting point and the end
   of the storage medium; no attempt is made to preserve files that follow
   if you decide to write more data than was set aside.

3. When using setbuf(), the traditional "null buffer" denoting that I/O is to
   be unbuffered is more-or-less ignored since all data is always buffered
   either one disk block's worth (for disk files) or not at all for terminal
   I/O. A buffer is kept around merely for dealing with partial block
   reads/writes and nothing more. If you pass a buffer larger than DBLKSIZE
   to setbuf(), it won't save you anything as the extra space will never be
   used. I provided setbuf() simply for those who might like to have more
   control over the physical location of this buffer.

4. The various file control options are totally different than those of
   UNIX. For that reason, different function names were used to prevent
   confusion.

MINOR CAVEATS:

1. All I/O is implemented straight with the fread()/fwrite() calls. There are
   no intermediate "file descriptors" and thus no read()/write() calls. Since
   most or all Unix applications that use fd's directly can usually be adapted
   to use fread()/fwrite(), you can probably adapt the program without losing
   any significant UNIX compatability. This really won't help you a heck of
   a lot when porting things like the standalone mkfs, however, since things
   in this catagory seem to expect a more complete open()/close()
   implementation with a fake devsw lower down. I am working on this at the
   moment.

2. All the functions that used to be "macros for speed" like getchar() were
   implemented as functions. I don't expect to hear anybody complaining
   too loudly, what do you expect for stand-alone?

3. ungetc() is limited to one byte of pushback. This is probably not a
   problem at all since most programs still assume a one character limit for
   compatability with older Unix systems. I could change this, but I don't
   really feel like it. Let me know if it really causes you problems and I'll 
   think about it some more.


			Viel Spass, alles..


				Jordan