On Sun, 25 Jun 2006 13:14:29 -0400 James Carlson wrote: > Felix Schulte writes: > > On 6/25/06, Casper.Dik at sun.com <Casper.Dik at sun.com> wrote: > > > This seems wrong; personally I think we should rip out any replacement > > > for system libraries; such duplication leads to more code which needs > > > to be maintained. This includes replacements for <stdio.h>. > > There would be no need to replace it if the stdio implementation in > > Solaris would be sane, however since it sucks a faster, non-sucking > > replacement would be cool.
> 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? 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) the stdio wrapper could be removed but that might affect external ast ksh builtin implementations that use stdio (they may chose to use the more familiar stdio, knowing that the ksh/ast/libcmd sfio hooks/performance will still work) if the balking is about ast using sfio instead of stdio (I don't think it is), well, ast+sfio are inseparable we can provide reasons why if anyone needs them btw, how does solaris deal with gcc+glibc and its stdio implementation? -- Glenn Fowler -- AT&T Research, Florham Park NJ --
