Subject: Re: Why does ksh/libshell use ast stdio ? / was: Re: [ksh93-integration-discuss] comments on rev 287 makefiles --------
While this issue has been mostly addressed with several other e-mails, let me provide some background and some clarifications. First of all Phong Vo and I created SFIO (Safe/Fast/IO) about 15 years ago because of our frustration with STDIO implementations. ksh88 used read/write directly because STDIO implementations could did not give correct behavior; expecially with fork()/exec() and with signals. Initially we thought that we could just create a STDIO library that was portable and worked, but we discovered that the STDIO interface was inconsistent and lead to inefficiencies that could not be rectified without a new interface. For example, the interface for reading a line requires that you know the maximum line length. Safety issues such as sprintf() are now well understood, but we were aware of them at this time and resolved them. Additionally, we made SFIO streams work for strings as well as files. Anyway, we created SFIO which has a consistent interface (the stream pointer is always first, buffer pointer comes before size, and flags last). We added an sfio.h header that mapped STDIO into SFIO so that we could run existing commands and compare. We also created a binary intercept library so that existing .o's could be linked with this library and use SFIO rather than STDIO. We presented this at a USENIX conference showing how it beat all the existing STDIO implementations in performace and added functionality such as the ability to use memory mapping and to add extensions. Over the years, SFIO has been steadily enhanced. In addition to I18N, thread safety, large files, major enhancement to sfprintf() for an extensible architecture have been made by Glenn Fowler and Phong Vo which resulted in a second USENIX paper. ksh93 uses SFIO only, not STDIO. However, users can compile libraries of built-ins that are written using STDIO by using making sure that the AST STDIO header comes before the standard version. If Solaris only wants a single STDIO implementation, one alternative is to replace STDIO with with the AST SFIO/STDIO package. However, this is by no means necessary. What is needed is to make sure that the ast/stdio.h header is used when building built-in extensions. The AST sfio.h maps function names with ast_ prefixes so that it will not cause linking problems. Note that SFIO is OpenSource as is used by other non-AT&T software. For example, Perl has a compilation option that uses SFIO. David Korn dgk at research.att.com
