Sfio is a library for managing I/O streams. It provides functionality similar to that of Stdio, the ANSI C Standard I/O library, but via a distinct interface that is more powerful, robust and efficient. Below are some desirable attributes of Sfio:

• There is no limit on the number of open streams imposed by the library except as standardly regulated by the underlying operating system via available memory or the allowed maximum number of open file descriptors.
• There is no arbitrary limit on file sizes. On systems supporting 64-bit files, Sfio will be automatically configured to support the same.
• Streams can be safely used in multi-threaded applications. Further, Sfio allows an application to choose when a stream should be thread-safe so that it can avoid expensive thread-safe operations when a stream is only privately used.
• Sfio enables exact synchronization of seek locations in file descriptors shared across streams and/or processes. This allows an application to safely share file data across processes even with buffered data in streams.
• The buffering algorithm for reading streams is adaptive so that it performs well with both sequential and random access I/O. This avoids wasting of buffered data in the face of random accesses.
• The buffering algorithm for writing streams takes advantage of holes in data (ie, long sequences of zeros) to minimize the number of disk blocks used. It also automatically avoids issuing system calls on a /dev/null stream.
• Data formatting functions are supported by efficient algorithms for integer and floating point value conversions. They transparently handle multi-byte data as defined in the ANSI-C Standard. Applications can extend the formatting capability by defining new formatting directives or redefining existing ones.
• Sfio's I/O disciplines provide a mechanism for applications to extend the system-level I/O primitives with additional data pre/postprocessing. The library includes a subpackage of example disciplines showing various functionalities such as making an unseekable stream seekable, or automatically decompressing compressed data, etc.
• Streams can be stacked so that their data can be processed as if they are in a single virtual stream. This enables treating nested files (e.g., #include's in C programs) as if they are single files.
• Related streams can be pooled so that synchronization can be done as different streams get accessed, for example, automatic flushing of buffered data in a writing stream before accessing another stream.
• Operations are provided for directly accessing a stream buffer to avoid memory copy.
• Operations are provided to read and scan lines and records of any length so that buffer overflow is automatically avoided.

Sfio provides both source and binary Stdio emulation packages so that existing applications based on Stdio can take advantage of Sfio's features. The source compatibility package includes a header file stdio.h that translates Stdio calls to corresponding Sfio ones. The binary compatibility package is a library implementing all known public and semi-private functions from different versions of Stdio on top of their Sfio counterparts. To the extent that we know, these Stdio compatibility packages safely enable mixing and matching modules based on either Sfio or Stdio.

Sfio has been ported to most known UNIX platforms including various flavors of IRIX, SUNOS, Solaris, Ultrix, MVS/OpenEdition, Linux, BSDI and UWIN.

Below are papers related to Sfio:

• David G. Korn and Kiem-Phong Vo, ``Sfio: Safe/Fast String/File IO'', Proceedings of the Summer '91 Usenix Conference, pp. 235-256, 1991.
• Glenn S. Fowler, David G. Korn and Kiem-Phong Vo, ``Feature-Based Portability'', Proceedings of the Usenix VHLL Conference, pp. 197-207, 1994.
• Kiem-Phong Vo, ``The Discipline and Method Architecture for Reusable Libraries'', Software - Practice & Experience, v.30, pp.107-128, 2000.
• Glenn S. Fowler, David G. Korn and Kiem-Phong Vo, ``Extended Formatting with Sfio'', Proceedings of the Summer 2000 Usenix Conference, 2000.

Comments/Questions/Problems

Except for configuration problems in building the package, a bug report should be in the form of a small program that I can compile and run. Without such a program, I will likely ignore the report since it often takes too much time for me to tell if a reported bug is real or if it's just a misuse of the code.