James Carlson wrote: [snip] > That's the part that's unclear to me. If the issue is *just* sfio, > then the root architectural issue is whether those features sfio > provides ought to be here or part of libc. If it forces this > projectto reimplement stdio, I'd expect that there'd have to be a > really compelling explanation of why sfio features don't just belong > in libc. > > But from the word "sucking" used by the previous poster, I get the > impression that use of ast stdio is also working around some known > bugs in Solaris stdio. (What else could "sucking' mean?) If that's > true, then I disagree that tossing another stdio variant into Open > Solaris is the right thing to do. It makes much more sense to fix the > one that's there than to fork off and create another maintenance > hazard.
"sfio" is not another "stdio variant" - it's completely different beast (excluding the stdio emulation layer tacked on top of it, see Glenn's posting about the reason for that). Please look at the manpages and sources. Another item for consideration is that libast acts as "portabilty layer" which is mandatory to get ksh93/libshell running on various platforms (AFAIK 30+). Sun didn't demand the removal of the portability layers in Mozilla/Firefox, Gnome, Apache etc. prior their integration into Solaris so I assume it's more than fair to not demand that from ksh93/libast, too. ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
