Garrett D'Amore wrote: > Roland Mainz wrote: > > Richard Lowe wrote: [snip] > As to this particular case, I feel limited use in some applications is a > different proposition than globally searching ON and converting most of > it wholesale.
Erm... that was not my intention. I am NOT planning to take over OS/Net and/or convert every application in OS/Net which can't climb up a tree fast enough to use libast or turn it into a ksh93 shell script... :-) > In the former case, limited library use makes sense, in > the latter case maybe this functionality really should be part of libc. Please take a look at my other email for that... > As to whether there should be a giant paradigm shift towards some common > stdio from what we are doing, I agree with the original poster that > "justification is required". Why would we want to change? Possible options/justifications (in the case of using libast in OS/Net) include (but not limited to, just what I still remember at 6:03am on Sunday): - Improved performance (for example in almost all cases where we did benchmarks sfio was faster than Solaris's stdio implementation) - Better functionality (Ok, that's debateable since some of the benefits may be the result of the enforced usage of XPG6/C99) - Reduction in code size - Reduction in memory footprint - Simplification of code > What are the > benefits? And the costs? From what I've seen so far, you have a > tendency to see costs vs. benefits with a certain subjective view, that > doesn't necessarily concern all use cases (e.g. not all Solaris users > are writing ksh scripts that need to work with terabytes of data.) > Examination of the tradeoffs for major changes is certainly, IMO, warranted. For ksh93 (and only for ksh93) my tentency is too look at the current and _future_ usage and even cover the one or other "edge usage" which is still important like support for the zh_CN.GB18030 or ja_JP.PCK locales (which are both "pet projects" of the respective governments) or making sure not to establish artificial barriers like adding a new shell to Solaris which is not capable of dealing with 64bits (this is a minority right now but I expect that this may play a more important role in the future. There are already complains about the 32bit-only "perl" in Solaris and the "solution" of NIH was to move the applications over to a platform which has a 64bit "perl" by default (suprise suprise, this was not Solaris...). Why should a shell which has support for large arrays and trees NOT have 64bit support ? 64bit is one of the MAJOR selling points of Solaris...) by default. ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
