Glenn Fowler writes: > > In that case, the right answer is to remove the "sucking" part of the > > Solaris stdio. Since stdio is part of Open Solaris, this is doable. > > I'm not sure what the issue is here > > fixing/improving any part of any stdio implementation is non-trivial > isn't that what ``remove the "sucking" part of the Solaris stdio'' would > entail?
Yes. > balking about two separate stdio implementations is understandable > but the ast stdio implementation is a side effect of the fact that > ksh + the ast libraries use the ast sfio for io (not stdio) > ast simply provides a stdio wrapper on top of sfio so that non-ast > code compiled/linked against it can benefit from its performance/features > (e.g., sfio disciplines can be pushed on ast stdio streams) 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. > btw, how does solaris deal with gcc+glibc and its stdio implementation? We don't have to, because gcc and glibc aren't integrated in Solaris. (Yes, glibc is indeed a problem looking for a place to happen.) -- James Carlson, KISS Network <james.d.carlson at sun.com> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
